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

Max Horn max at quendi.de
Tue Oct 5 18:11:16 CEST 2010


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