site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com On Mar 17, 2009, at 7:58 AM, Paul Miller wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... If your plugin maintains a lot of data that can be regenerated if necessary, the best thing to do is to use the singleton approach to manage the memory across multiple instances of your plugin. Of course, this breaks down if the user has multiple instances of plugins from multiple vendors, each implementing their own static pool of scratch memory. But it does greatly contain the problem. Can a plugin subscribe to NSTimer events, or would that be no-no? If so, a plugin could set up a periodic timer and flush caches every x minutes of inactivity or something. Though I don't know if this would play nicely with your real-time stuff. Cache flushes will make the plugin behave in a very non-realtime manner, but if the alternative is to have FCP VM thrashing, or crashing, then I'll take the performance hit over data loss. This email sent to site_archiver@lists.apple.com