[Scummvm-devel] Memory consumption in GUI branch

[Neil Millstone]

Max Horn wrote:
>
> 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
>
Hi Max,

The code growth you mentioned does sound a little worrying, if the same 
is seen on the DS build (ARM code tends to have quite poor code density) 
then ScummVM is unlikely to run properly anymore, but as you said, only 
a single bit format is used for the GUI, so that should help.

Loadable modules would help to an extent, but most of the builds only 
contain one engine anyway, especially for those which are having memory 
issues, so it won't help in those cases.

I will let you know more once I'm back home.

Regards,

- Neil