Maybe it's the problem in my configuration? Does anybody experience the same thing?
1 person found this helpful
Do you have the debug flag set (in the CSXSPreferences plist on Mac, or the registry on Windows)? This will actually be done automatically using run/debug/attach as in Extension Builder, and is necessary to run unsigned extensions. If so, this isn't so much a bug as a feature.
With that flag set CSXS will load itself in a debug Flash Player. In a debug player memory is not freed by garbage collection in the way it is in the release player, as there is an expectation that the developer may wish to track its usage with the profiler APIs.
The reason why Photoshop jumps so high with each panel open/close action is because it is loading the SWF into memory each time. In the release player this will be cleared out, but with the debug player it will not.
Can you try your test SWFs with the CSXS DebugMode flag reset to 0 (or removed)? I think you should see more representative usage with that. Bear in mind, of course, that with that set you'll have to install the plug-ins via Extension Manager. Extension Builder will automatically set this flag back to 1, so you cannot use run/debug/attach as to check this behaviour.
James, thank you for the very fast answer! I did various tests on the weekend on my computer and computer of my friend.
And I can say, that Debug flag doesn't affect memory consumption. They still eat memory. My steps to reproduce are as follows:
(Windows 7 32 bit)
1) set HKEY_CURRENT_USER\Software\Adobe\CSXS2Preferences\PlayerDebugMode to 0
2*) check HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\CSXS2Preferences (just in case)
3) Compile HelloPhotoshop example to ZXP and install via Extension manager
4) restart computer
5) Run Photoshop CS5 - Memory consumption: 100 096 KB
6) Open HelloPhotoshop and close it 10 times
7) Memory consumption: 155 840 - 5,574 MB per one close/open
Maybe a garbage collector is expected to run and free this memory, but it never happened in my case. The memory pool was increasing to 1 GB when I was working with one of my panels - with no documents open in Photoshop
In InDesign I tried the same thing with HelloInDesign ( I had to close the panel completely and then open with Window | Extensions | HelloInDesign)
Memory consumption on start: 118 516
Memory consumption after 10 open/close cycles: 197 516
It's 7,9 MB per one close/open
It's the simpliest panel test. When I'm using AIR libraries the memory usage is increasing a lot faster.
1 person found this helpful
Looks like in the Helloxxx samples, we use mx:WindowedApplication, which has a known bug for not releasing memory on close. So for CSXS extension, it's better off with mx:Application or csxs:CSXSWindowedApplication. I've just tried mx:Application with the HelloPhotoshop, and it seems the extension's close does bring the memory usage down. Note that a StageManager is used to load all the extension, so on the first launch of any extension, you will see a rise in memory which accounts for StageManager + the extension. When the extension is close, the StageManager does not close, so you won't see the memory go back to where it was, but you should see the footprint goes down. Also note that you will see a different behavior in debug build as James had pointed out earlier.
I've fixed the HelloXXX samples, so it uses mx:Application now. Thanks for reporting this issue to us.
Thank you for the answer! Great I was of help!
But I'm using CSXSWindowedApplication, which was recommeneded.
I made another test with HelloPhotoshop example, moving to CSXSWindowedApplication. The leak was greatly decreased, but it still is there.
I turned the debug mode off in registry as well. After 20 open/close cycles there's still a leak of 10MB, 500Kb per one close/open in HelloPhotoshop.
In my own extension, which is using AIR very extensively, the leak is much greater - about 10MB per one open/close. (Debug mode turned off, CSXSWindowedApplication).
Lee, thanks again for the replies
I'm back with the bunch of tests - you know, it's so hard to find the leak in CSXS panel, because any debug info increases it. And that was tough!
I had to remove the registry switch, the "debug" file in Photoshop folder and export the release version of the project, like 50 times to test the panel in clean conditions.
Now the panel eats only 2MB per one close/open. I couldn't make it any smaller - it seems like memory is being freed by some very complicated algorithms. If I test a blank panel, and open/close panel, like 10 times - the memory is rapidly increasing up to 5-10 MB and then increases very slowly with every open/close.
If I test a fully featured panel and open/close it 10 times, the memory rapidly increasing by 20-50MB and then is increasing very slowly with every subsequent open.
On the average a fully featured panel eats about 1-2MB per open/close in sequence of 20-30 cycles. And a blank panel eats about 500KB in the same sequence.
So the bottom line of my tests is that there is a small memory leakage (500K - 2MB), when you export a panel in a release mode and turn OFF all the debug flags (including registry and "debug" dummy file). It's not so big, but it exists.
I've tried HelloPhotoshop with CSXSWindowedApplication too, and it appears to me the Photoshop memory usage hops around 138800K on every close. One caveat is I am testing it on XP, and you're on Win7. I was trying to run it in Win7 but my Win7 VM is hosed. However, I felt my XP result is kind of matching what you have seen now. Please note that once an extension is loaded, you will see some increase in memory that will not be reduced even if you close the extension. Because a StageManager will be loaded to host the extension, and it is basically the player that will host all the subsequent swf. In my case, my first launch of any extension, I will see an about 3MB increase that will not go away even my panel closes, which is expected.
As you have already found out, running in debug build has a lot of things going on, so reading memory usage only when you are in release build, installed through ExtensionBuilder, a couple things to make sure here:
1. Your CSXSWindowedApplication based extension is installed thru ExtensionManager, and run from Photoshop, as opposed to be launched from ExtensionBuilder.
2. Make sure there is only one copy of HelloPhotoshop running. i.e. if you have launched thru ExtensionBuilder, there might be another copy of HelloPhotoshop in your user folder?
Thinking out loud:
Is it possible that the Marshall Plan structure leads to dangling event listeners?
Do event listeners get cleaned up when a panel is closed? If I understand it correctly, the Flash engine will not garbage collect event listeners as long as an app is running. If the "running app" is the Stage Manager, I would think that event listeners of individual panels would get stranded when they are closed. These standed event listeners might account for the memory leak...
that is great possibility we can take it to test. Thanks for sharing
Just wanted to let you we really appreciate your report on this, we
have definitely take note on this and will be looking into it. I am
also wondering if it's possible you can share your extension or code
snippet with me so I can investigate it further?
Lee, thank you very much for support! It's so great that my tests are not in vain
My project is too big to post it, I'm sorry.
But I experienced a small leak with HelloPhotoshop example, when I opened and closed it 20-30 times. Maybe 10MB increase in memory usage (and in my own panel the leak was bigger)
With regards to potential causes, it may also be worth reading http://blogs.adobe.com/aharui/2009/08/what_we_know_about_unloading_m.html
There are some things that we know will cause memory leaks in parent/sub-swf loads, and I wonder if one (or more) of these could be at play in your application.
Also, with regards to running in debug mode, I find a good (albeit somewhat rudimentary) way to be absolutely certain that your extension is running as release is to throw and catch an error, then attempt to print the stack trace to a text box. In release, this will be a null string - so if there is text you know that the player is in debug mode.
Thank you, James!
There are lots of info, I'll be looking into it!