[Scummvm-devel] Memory consumption in GUI branch

Max Horn max at quendi.de
Fri Oct 3 18:45:54 CEST 2008


Hi all, hi Vicent,


I used a nice Apple tool (Instruments.app) to study a bit where we use  
what kind of memory in ScummVM. In particular, with the GUI branch,  
and using
   -eadlib -g1x
as well as the classic built-in theme, figuring that this should be  
the setup using least memory and being common to portable devices.  
What I noticed:

* The SDL backend uses the biggest chunk of memory, for graphics  
buffers. Custom backends will differ, so I am not caring about that  
for now.

* A lot of memory is allocated by the OS itself, for audio resampling,  
graphics, etc. -- this is of course OS X specific, so I won't bore you  
with it.

* We allocate two 256K buffers in InitLUT -- that's used by HQ2x/HQ3x,  
so I hope it won't affect low-end ports.

* Apparently, ThemeEngine::screenInit allocates two 155648 bytes  
buffers (for Graphics::Surface). Note: OS X rounds memory block sizes  
a bit, but I guess those buffers are 320x200x2 big. That's 300KB in  
total. I wonder if we really need both of these?

* XMLParser::parse() invokes new about 560 times, to allocate  
ParserNodes (each taking up a 1024 bytes block over here) -- that's  
far from the couple millions we used to have, but still not quite  
optimal. I think those are only kept around temporarily, so I am not  
concerned about memory use, only about the number of allocs (which  
might grow for bigger / more complex XML files, right?). So, it might  
help to keep a (Fixed)MemoryPool for the ParserNodes, to reduce the  
number of allocs. Would be easy enough to implement that.

* A big chunk of memory is used to represent my huge config file  
within the ConfigManager. A lot more than what the file size of the  
config file would suggest. So, I guess working on that would help to  
get down memory usage, at least for "power users". This holds for  
trunk, too, and is independent of your GUI work, of course.



All in all, the GUI branch seems to be quite good when it comes to  
memory consumption, with the possible exception of those two memory  
buffers -- but I think those are in trunk, too, so it's no regression.

Over all, I think we could merge this




More information about the Scummvm-devel mailing list