[Scummvm-devel] Memory consumption in GUI branch
Max Horn
max at quendi.de
Mon Oct 6 14:22:20 CEST 2008
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
More information about the Scummvm-devel
mailing list