[Scummvm-devel] Bi-annual ScummVM binary size email

Max Horn max at quendi.de
Tue Oct 5 22:25:51 CEST 2010


Am 05.10.2010 um 18:28 schrieb Neil Millstone:

>  Hi Max,
> 
> A tool like that would be very handy.  Although it would be hard to 
> match together versions where large chunks of code are 
> changed/renamed/moved, perhaps just indicating those sections would be 
> useful.

Definitely would be worth it. In the best of all worlds, we could even automate it and run it as part of our buildbot with the nightlies (or even with all builds). We could then even graph the size changes for each engine over time, which would help pin-pointing particular bad cases of code size increase ...

Obviously I am just dreaming here... :) 


> 
> I'm going to have to get reading the binutils manuals...

As a first approximation, we could just record / track the size of the various lib*.a files, e.g. engines/*/lib*.a 

I also tried the following (which isn't too helpful on the .elf, but the same command can be run on .o and .a files).
 /opt/devkitpro/devkitARM/bin/arm-eabi-nm -C -S  --size-sort -r  scummvm.elf
but that might actually be too fine grained...



> 
> For the future, it might be worth making it possible to split off some 
> of the larger chunks of static data (the credits text in the about box, 
> the built-in theme xml, etc.)

On trunk, it should be possible to disable the built-in theme XML via #define DISABLE_GUI_BUILTIN_THEME.

On the branch, you'll have to modify gui/ThemeEngine.cpp, commenting out the line that says
#define GUI_ENABLE_BUILTIN_THEME

I recently changed that on trunk; I guess it could be backported to the branch if it actually works (I did *not* try compiling or running ScummVM with DISABLE_GUI_BUILTIN_THEME on).


> into separate files that I can load from 
> disk on startup.  That would prevent them from being resident in memory 
> at all times as they are now.

Aye... Well, our GUI theme code could also still be slimmed down by getting rid of that XML parser, replacing it by a lean-and-mean binary format parser. This was discussed in the past, but nobody ever got to it (Tanoku/Vicent wanted to look at it at one point, but well, he's moved on to other callings since then :-).

> 
> I'm not sure what we can do about the current release, but there's got 
> to be something I can out cut to save 20 - 30Kb.

Yeah, I certainly think so.

Cheers,
Max



More information about the Scummvm-devel mailing list