Does anyone know if/when Fireworks will get a memory overhaul?

Question

Hi There,
I know many people on this forum don't run into this issue - but does anyone know if Adobe is planning on sorting the memory issues in Fireworks?
More and more, the only way we can use Fireworks is by splitting documents and reducing the number of undos to 1 which makes using symbols (a massive advantage over Photoshop IMHO) unusable. We've tried sharing sysmbols between multiple documents but updating them was so slow it wasn't practical.
If you're thinking "Why would you need more memory - he must be doing it worng" try designing sites with multiple scrolling pages like this one from apple: http://www.apple.com/macosx/whats-new/ Not all clients and developers require a site to be mocked-up like this - but many do.
I'm sitting here on a production workstation which has 12GB of ram but FWCS5 only ever seems to use between 1.77 and 1.8GB (viewed in activity monitor).
Does anyone know if:
- CS5.1 fixes this?
- Adobe plans to fix it in the future?
- Adobe plans to keep Fireworks alive?
Please note, I'm not trying to create any forum Fireworks (ah hem) I'm just at a point where I'm seriously evaluating other options for our production workflow - it will be a sad, sad day if Adobe kills this product but patching it up and not dealing with fundamental issues is also not working for some us.
Any help or pointers people have discovered to get around the issue (or any insider information on Adobe's plans : ) would be much appreciated.
Regards,
Ben

Answer 1

I've had some luck minimizing the memory bloom by:
- minimizing the use of buttons with multiple states
- minimizing the use of buttons with editable text
- avoiding shared layers - which seem to be shared, but also seem to baloon the memory usage (as if they aren't really symbols but are rememberd as unique sets of pixels)  For instance when I removed the iPad frame that surrounded my screens from a shared layer, the memory usave plummeted.
- using styles instead of symbols as much as possible
- minimally using master pages
- avoid pixels at all cost - use vectors as much as possible, trim masked imaged more closely
- avoid abobe photoshop effect styles, they seem to take up more memory and are more restrictive anyway.
- avoid protoyping demos with rollovers and other animations, stick to static screens as much as possible
- avoid paging through your file agressively - each page you look at loads that part of the file into memory.  So if you hit "page up" 30 times to get to page 30, you might be getting close to your ceiling.  But if you go directly to page 30 then you have a better chance of keeping your memory allocation from maxing out.
It's not that you should avoid using these features completely, but to do so in simpler ways.  I usually try and stick with one primary method (simple symbols) and one supporting method (styles) and so far, even on a doc that's over 100 pages, no crashing. 
If you have symbols within symbols with hovers built into editable buttons scattered across hundreds of pages with some shared layers, some excluded layers, some master pages, some variant pages, and the app will grind to a halt, crash for no reason, and file may never open again.
None of this fixes the problem.  The problem is Adobe's to fix.   But they do help.