[Scummvm-devel] Memory consumption in GUI branch

[Max Horn]

Am 06.10.2008 um 11:26 schrieb Neil Millstone:

> Hi,
>
> I am currently travelling in Japan for the rest of the month,and so an
> unable to test this new GUI branch.
>
> I would mention here that the DS port is extremely low in memory in  
> some
> places.  Especially in Inherit the Earth, where I'm 100Kb from the end
> of memory at some points.  Also, keep in mind that the size of the
> binary executable also makes a big difference on this port, so it's
> worth watching that as as well as the size of static and dynamic
> allocations.

Hi Neil,


noted, we'll try to keep this in mind :). But this is only theory.  
What we really need is people actually trying the code and telling us  
how it performs on actual low-end devices, as any tests you do on a  
desktop can only approximate the real experience to a low degree..

So, we look forward to you returning, and testing the memory  
consumption after the GUI merge, and also how the recent string class  
& memory pools changes affect memory usage for you (on OS X, it saved  
a couple hundred KB, but this number is distorted by the fact that the  
OSX memory allocator always rounds up sizes of allocated blocks to  
certain fixed sizes).

Oh, and of course, a way to generated loadable modules on the DS and  
other ports would be super-sweet (we had that subject on the list  
already -- essentially we need a dedicate coder to do this. Seems like  
an excellent task for GSoC 2009).


Anyway, here are the binary sizes for a release build (with --enable- 
release, i.e. -O2) on my OSX 10.5.5 machine.
trunk before stripping: 8637528
trunk after stripping: 7396560

gui branch before stripping: 8773476
gui branch after stripping: 7526408

Hence, there indeed was some code growth. Tsk. I guess the gui/vector  
stuff making liberal use of templates doesn't help here. We might be  
able to save some space if we allowed the code to be compiled for a  
single bitformat (I assume that on the NDS and other small devices,  
only a single bitformat is used, so if we provided a #DEFINE to  
restrict to one, that would reduce code size w/o impacting usability  
of the code, right?).


Cheers,
Max