Optimization of Modest Maps for embedded systems
I am currently working on an implementation of Modest Maps for an embedded platform. I have noticed that memory usage tends to increase over time and that the garbage collector has trouble managing the memory allocations. I have noticed that some event handlers are strongly referenced and I am concerned there might be more serious leaks in the source.
Therefore, I plan to add a memory management function to narrow down troublesome paths in the source and eventually optimize the source to reflect the discoveries. If someone is already working on this I would be happy to join forces.
Thank you,
Nicolai
Therefore, I plan to add a memory management function to narrow down troublesome paths in the source and eventually optimize the source to reflect the discoveries. If someone is already working on this I would be happy to join forces.
Thank you,
Nicolai
1
person likes this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?Hi Nicolai,
I have done a significant amount of testing in the subversion trunk to make sure that memory does not get out of hand in the core classes in Modest Maps. If you're using the downloadable version from modestmaps.com I can strongly recommend switching to the current subversion trunk.
If you're using subversion already, and still have memory issues, please expand on the scenarios where memory is an issue and I will try to help track the leaks down.
The default cache sizes for objects are quite large, so memory will increase quite rapidly when panning and zooming around a map. However if you switch providers (for example) it should go down again. The TileGrid exposes maxTilesToKeep which you should be able to safely set to 0, but there is also an object pool (the TilePool class) which does not currently expose any parameters.
I seem to be asking this a lot recently, but can you post a minimal example where memory usage is a problem? -
To expand on this a little... when I say "significant amount of testing" I mean mainly around the scenario of having one Map that exists for the entire duration of an application instance. If you're creating and removing lots of Map instances that might be a source of memory leaks due to the strong references in the listeners that you describe. -
Inappropriate?There is a known problem with memory if maps are destroyed, I don't know if this has been fixed in the source you are using. If you search for "memory" on this forum you will find the topic.
-
Inappropriate?Thank you for the quick response and thank you for the pointer to maxTilesToKeep and the TilePool. I will experiment with these first.
We will still, most likely, have to integrate memory monitors in our code to narrow down the occasional memory leaks. I will be happy to share the discoveries in the forum when I know more.
I’m happy
-
Inappropriate?I've been looking at the memory of my application (using few differents maps at the same time) and i have to say its pretty well managed. The object pool is per defauly using max env. 60Mo per layer in memory but you can modify this value using the DEFAULT_MAX_TILES_TO_KEEP constant in TileGrid.as (default is 256 tiles kept in memory).
After that, the object pool used to increase performance does his job and memory doesn't get off the roof.
If you are trying to find some leaks in an application, i strongly recommand the Flex Profiler that comes with Flex Builder 3 (works with pure AS projects too). If you are not familiar with this tool, it helps keeping track of live objects (and their back references), memory usage and performances.
I’m confident
-
Inappropriate?I appreciate your comment on Flex Builder 3. I was not aware it had such a dertailed memory profiler. Exactly what I was looking for in Flash CS4. Thank you.
I’m thankful
Loading Profile...



EMPLOYEE
