At 11:10 +0530 08/01/03, [EMAIL PROTECTED] wrote:
If you follow the help-example and do like so:<snip> timeoutObjects that doesn't release their targetObjects, because of a bug, if you don't initialize them into a variable. <snip>Thats a new one for me. Can you elaborate?
timeOut("name").new(1, #method, object)
without assigning the result like so:
t = timeOut("name").new(1, #method, object)
Then a bug will cause the timeoutObject to not release it's reference to its target object, at the point when garbage collection would usually occur.
If such unreleased objects holds large imageObjects as properties, then they can quickly gobble up heaps of memory.
At least on Mac, when apps had a fixed memory-space, it used to be so that freeBytes showed you the total amount of free memory left, while freeBlock showed you the largest contiguous block of memory.<snip> Or maybe you're allocating memory in such a way that the memory-space quickly becomes fragmented. When your memory space is consumed to the point where there is no more available RAM, virtual memory on the harddisk will typically be used, and that could seem like a "grinding halt". Anyway, if you think that memory could be the issue, and you haven't explored that yet, you should look into things like the memory-inspector, and lingo such as the freeBytes and the freeBlock. <snip> I always thought that Director managed the memory part on its own and I didn't really have control over that. How can I see the fragmentation?
Thus even if you managed to keep sufficient amounts of 'freeBytes', you could still wreck your app, if the freeBlock dropped below the size needed for such things as images and sounds.
Like I said, I'm not quite sure how these commands work in a modern memory space, for instance any app on OS X gets a 4 GB virtual memory-partition to play with.
Maybe I'm overcomplicating the issue here, by talking of leaks and fragmentation.Actually, when I'm running the movie in authoring mode and keep the Memory Inspector open, I see a big leap in the red bar. On stopping, this memory is not released immediately, but if I click on the Purge button, it gets cleared considerably. If I play the movie again, the performance is good again.
Maybe it's just that you keep loading new media assets, and as Director thinks it has some nice big/unlimited (virtual) memory partition to play within, it never unloads anything, but just keeps consuming more and more memory, until it's far into swap-land.
If that's the case you should be able to alleviate the problem by unloading your assets from time to time.
You can do that asset by asset, but as you say time is of the essence you could probably just do with some unspecified 'unload' or 'unloadMember'.
At least you could just start there and see if it affects the situation at all.
Memory management is often a game of trade offs, but in your case it could be a simple trade off:
Either come to a grinding halt, or suffer a smaller drop in performance, when assets have to reload from time to time.
If the issue really is that you're battling heavy harddisk swapping then I think all other optimizations will be futile meanwhile.My best bets for the moment seem to be controlling the memory fragmentation and drawing faster. I think I'll go the imaging way.
If you are generally able to hear harddisk activity on your computer, then you should be able to monitor excessive swapping by ear. Does harddisk noise increase proportionally to the perceived slowdown?
Otherwise there are probably utilities that can indicate harddisk activity, and probably also more specifically swapping activity.
Jakob
[To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
