[Scummvm-devel] ScummVM binary size comparison
neil at millstone.demon.co.uk
Sat Nov 8 16:02:07 CET 2008
Max Horn wrote:
> Am 08.11.2008 um 00:23 schrieb Neil Millstone:
>> > Hi Max and Team,
>> > So I used Max's handy command from an earlier post to find the biggest
>> > object files. I'm compiling with my normal settings. ARM instruction
>> > set mode (I'm sure thumb mode doesn't work with the current compiler),
> It would still be a good thing to determine where it doesn't work,
> precisely, and to report this to upstream, to get it fixed. According
> to Robin, the binary size goes down several hundred KB, which we'll
> never be able to cut by optimizing our code manually.
I'm going to do this, but tracking these random crashes with no debugger
takes a very long time. Working out a minimal piece of code which
replicates the error takes even longer. I get the feeling that Tramboi
or Robin would be better at this than me!
I think this is the wrong solution though. I had a version of 0.9.1
that can run The Dig and Full Throttle. I only managed this by
compiling with Thumb and turning optimistaions off. If we need to use
Thumb just to keep games working that worked a few months ago, there's
going to be no chance of getting the binary down to the size it was then
in order to run The Dig/Full Throttle.
And what do we do next time the binary grows?
>> > So, any ideas on how this can be improved?
> #define DISABLE_FANCY_THEMES
> #define VECTOR_RENDERER_FORMAT 1555
> resp. the equivalent -D options. Then recompile. That might help a
> little bit.
That's already in there.
> Next, I noticed that the built-in theme takes up 35k alone (I think
> the old one used a similar number, though). Specifically, gui/themes/
> default.inc is 38870 (of course, you have to subtract a couple
> thousand bytes for quotation marks etc.).
> With a trivial trick I was able to save 4k in my binary: I opened gui/
> themes/default.inc, and replaced all occurrences of " = " by "=", and
> likewise ", " by "," -- after removing several thousand spaces this
> way, default.inc was down to 35888 bytes, and the binary size was
> reduced by 4096 bytes for me.
> Since the DS only needs the 320x240 GUI layout, I stripped the high-
> res layout (by removing "gui/themes/scummclassic/classic_layout.stx",
> then running "python scummtheme.py default scummclassic". Then removed
> the whitespaces. Result: default.inc at 20976 bytes. In my case, the
> binary now was 16384 bytes smaller (on OS X, it'll always be a
> multiple of 1024 for technical reasons.).
> Extending this idea, we could shrink the theme even more if we apply
> some kind of compression. Using a perl script / preprocessor magic, we
> could automatically replace lots of keywords on systems with low
> memory (both in the XML file as well as in the theming code itself):
> "foreground" -> "fore", "drawdata" -> "dd", "drawstep" -> "ds", etc..
> In addition, we could store the data zlib compressed and decompress it
> on the fly.
Unfortunately, zlib is not compiled in for the DS port. So it would add
50Kb or so to the binary size to include it.
> No matter what we do, XML by itself always is wasteful, and doesn't
> compress *that* well... We could avoid this, if we developed a way to
> just dump the whole theme into a binary file, without concern for
> forward compatibility, and compiled that in. Then we could also omit
> the XML parser, and save even more space. But I am not sure whether
> that would be worth it...
TBH, I wouldn't have ever chosen to use XML on low spec devices. Not
just the DS, but also some of the other ports we have.
Tokenising this stuff into a binary format seems like a good solution
though. There's already a preprocessor script for this stuff, so it
would be an extension to that.
> BTW, is you code including scummclassic.zip or scummmodern.zip? You
> shouldn't need either, the built-in theme should suffice.
Nope, neither are included.
> Oh, and do we really need super-expressive internal names for widgets
> and dialogs? "GameOptions_Volume.EnableTabCheckbox" and similar
> strings really add up to a lot.
> Anyway, there is still a lot more stuff that grew, and we need to look
> into this.
I'm sure we'll find it!
More information about the Scummvm-devel