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

Neil Millstone neil at millstone.demon.co.uk
Tue Oct 5 18:28:25 CEST 2010


  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.

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

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.) 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.

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.

Cheers,

- Neil


On 05/10/2010 17:11, Max Horn wrote:
> Hi Neil,
>
> thanks. We definitely should look into those. However, it is a bit late in the release process to implement larger changes, so we'll have to see how effectively we can take care of this.
>
> Back to the growth issue: I wonder if we could whip up a tool/scrip which takes an NDS binary from a given release, compiles a table of symbols /code segments and their sizes, and diffs that against another version. By using "nm -S", sort, diff, you know.
>   That way, it might be easier to pinpoint which parts of the code grew specifically (or whether simply all of them grew, etc.).
>
> Cheers,
> Max
>
>
> Am 05.10.2010 um 01:07 schrieb Neil:
>
>>   On 04/10/2010 23:51, Max Horn wrote:
>>> Hi Neil,
>>>
>>> can you elaborate a little bit on which engines are affected how much. If that's easily doable for you, I mean -- it might help to motivate the right people to look at the right engines ;).
>>>
>>> Cheers,
>>> Max
>> Yes, I did this yesterday.  I have data for every build except build K
>> (Cruise for a Corpse).
>>
>> Here are the number of bytes larger the 1.2.0 builds are from the 1.1.1
>> versions of the same build:
>>
>> Scumm (A)  - 93696 bytes
>> BASS + Queen (B) - 15360 bytes
>> AGOS (C) - 39936 bytes
>> AGI + CINE + GOB (D) - 52736 bytes
>> SAGA (E) - 22016 bytes
>> KYRA (F) - 46080 bytes
>> LURE (G) - 49664 bytes
>> Parralaction (H) - 55296 bytes
>> MADE (I) - 67072 bytes
>>
>> It seems that Scumm is the worst.  The others haven't grown by as much
>> as 100Kb, but I would still love to get them back where they were, or
>> lower!  The gradual creep upwards it quite difficult to control.
>>
>> Cheers,
>>
>> - Neil
>>
>> ------------------------------------------------------------------------------
>> Virtualization is moving to the mainstream and overtaking non-virtualized
>> environment for deploying applications. Does it make network security
>> easier or more difficult to achieve? Read this whitepaper to separate the
>> two and get a better understanding.
>> http://p.sf.net/sfu/hp-phase2-d2d
>> _______________________________________________
>> Scummvm-devel mailing list
>> Scummvm-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>>
>





More information about the Scummvm-devel mailing list