No, you have no direct control over memory allocation. Also, Flex has long-since reached it's end of life. It's interesting that it's slow, since it sounds like you're neither CPU or Memory bound. My suspicion is that it's more likely that you're spending a lot of time in Flex framework code, which was written long before things like Retina and 4K displays, Windows 8, etc. It was always a fairly heavyweight technology, and there's a lot of new work involved when scaling things to high density displays while keeping them readable.
Because you're neither CPU or Memory bound, I'm kind of wondering if maybe there's something pathological happening with the Flex implementation. It's possible (and common) to write content that's constantly causing Flex to redraw the whole screen, which is going to significantly harm performance.
We donated the Flex codebase to the Apache Foundation several years ago, and it's still updated and maintained. You might find relief through updating to a current version of Flex, and can certainly get some expert advice from that community. Other folks here might be able to provide some concrete recommendations on what to look out for, but my focus has always been on lower-level ActionScript and C++ stuff. I'm not going to be useful in the tips and tricks department.
Thanks for the reply!
1 more question. How are the different browser plugins handling memory allocation differently? Because I run the same application across 3 different browsers, and IE performance is significantly worse than any other browsers. And I noticed through the Adobe Scout that memory allocations is very different.
My users refuse to use Chrome, and would like me to tune the performance for IE. So Specifically, is there anything related to IE as a browser, or the AxticeX Plugin that are restricting memory allocation or hindering performance?
I think you're going to see a significant behavioral split between IE on Win7 and below, and IE on Win8 and higher, and across IE versions. You're probably also going to see a difference between 32-bit and 64-bit IE, because of the per-process limits on addressable memory. Flash Player is automatically going to optimize what it caches based on available memory (e.g. we might cache intermediary rendered assets to avoid recalculating them when there's plenty of free memory, but choose to discard those assets and recalculate as needed as the process experiences memory pressure. There's a very direct tradeoff between CPU usage and the availability of reasonable amounts of unfragmented memory to either Flash Player or the host process.).
Each platform (browser/os combination) has it's own unique requirements and constraints, and there's a significant amount of security-related overhead. What's interesting to me is that IE (especially on older Windows versions) has the least amount of overhead in that regard.
So, on 32-bit IE with in-process Flash Player, you've got Flash Player and the browser sharing that single 2GB block of memory, where on 64-bit IE (with a huge per-process limit) or on Win8+ with out of process Flash, we're going to have a significantly larger operating footprint with which to optimize low-level performance.
There's not really much that you're going to be able to do in terms of controlling the behavior of an individual platform. You're basically stuck finding the worst-performing configuration that you need to support, and optimizing to it. The Flex framework itself is pretty heavyweight. One of the things you might consider is replacing the DataGrid with a lightweight class that you implement, or experimenting with disabling various properties on the DataGrid to see if maybe you're paying a heavy performance price for a property that you don't actually need.
The only thing you can really control about Garbage Collection is that you can manually invoke it:
You can also ensure that objects are available for garbage collection by calling dispose() and setting references to them to null:
Did Scout give you a sense for where Flash Player is spending time when processing this content? I'm still leaning towards the theory that we're waiting on something that takes longer to get thrown on IE.