[Scummvm-devel] Code size
Vicent Marti
tanoku at gmail.com
Sun Oct 19 13:09:18 CEST 2008
Are you serious? Not a single byte? ^^
That kind of sucks for me... And no, the code wasn't really stripped,
and the patch is supposed to remove quite a bit of unused junk. It's
very strange, I'll have to try it building the NDS port myself.
Vicent Martí
----------------
http://www.smartlikearoboc.com
On Sun, Oct 19, 2008 at 12:59 PM, Bertrand Augereau
<bertrand_augereau at yahoo.fr> wrote:
> Hi guys, I tried the patch with an Inherit the Earth DS build but I didn't
> notice any gain in the stripped elf.
>
> Is there any chance this code was already stripped on the DS? (unused)
>
> Cheers,
>
> Bertrand
>
> --- En date de : Sam 18.10.08, Vicent Marti <tanoku at gmail.com> a écrit :
>
> De: Vicent Marti <tanoku at gmail.com>
>
> Hey Max,
>
> I've just prepared a patch with some simple preprocessor voodoo to
> switch between a minimal vector renderer and the standard vector
> renderer at compile time.
>
> The standard renderer is exactly the one we have right now. The
> minimal one disables all templates, optionally skips the AA renderer
> and compiles the Specialized renderer for a single pixel format (565
> by default). Can somebody test how much does this reduce the NDS
> executable?
>
> Cheers,
>
> Vicent Martí
> ----------------
> http://www.smartlikearoboc.com
>
>
>
> On Thu, Oct 16, 2008 at 7:28 PM, Max Horn <max at quendi.de> wrote:
>> Hi folks
>>
>> we recently talked about the size of a scummvm executable and how it
>> grew with the merger of the GUI branch. I guess that is partially due
>> to the fact that we now have an XML parser, too... ;) But I figured it
>> might be helpful to generate some more data to figure out where we
>> might be able to gain the most.
>>
>> What I did was to compile a "release" binary for both trunk and
> the
>> 0.12.0 branch. So I run
>> configure --enable-Werror --enable-release [ lots of --enable-
>> ENGINE statements ]
>> and made fresh builds for both, on an Apple MacBook Pro, with Apple's
>> modified GCC 4.0.1. Our "--enable-release" switch ensures that
> -O2 is
>> passed to the compiler.
>>
>> I then sorted all *.o files by size of their TEXT segment. Since
>> engine code and infrastructure are kind of separate, I did this
>> separately independently on both. (I took the liberty of re-inserting
>> the column headers below for readability)
>>
>> TRUNK rev 34812, non-engine code:
>>
>> $ size */*.a | sort -nr | head
>> __TEXT __DATA __OBJC others dec hex
>> 87543 1180 0 0 88723 15a93
> graphics/libgraphics.a(hq3x_i386.o)
>> 65445 1204 0 0 66649 10459
> graphics/libgraphics.a(hq2x_i386.o)
>> 65016 1072 0 566 66654 1045e
> gui/libgui.a(ThemeEngine.o)
>> 54833 144 0 607 55584 d920
> gui/libgui.a(ThemeParser.o)
>> 46803 552 0 844 48199 bc47 gui/libgui.a(launcher.o)
>> 46585 424 0 71 47080 b7e8
> graphics/libgraphics.a(VectorRendererSpec.o)
>> 39371 36 0 364 39771 9b5b
> base/libbase.a(commandLine.o)
>> 32745 308 0 405 33458 82b2 gui/libgui.a(options.o)
>> 28307 1700 0 354 30361 7699
> sound/libsound.a(audiostream.o)
>> 22409 140 0 536 23085 5a2d
> common/libcommon.a(advancedDetector.o)
>>
>> $ ll -S */*.a
>> -rw-r--r-- 1 mhorn staff 736892 16. Okt 18:56 gui/libgui.a
>> -rw-r--r-- 1 mhorn staff 607148 16. Okt 18:56 graphics/libgraphics.a
>> -rw-r--r-- 1 mhorn staff 419884 16. Okt 18:56 sound/libsound.a
>> -rw-r--r-- 1 mhorn staff 365740 16. Okt 18:56 common/libcommon.a
>> -rw-r--r-- 1 mhorn staff 133636 16. Okt 18:56 backends/libbackends.a
>> -rw-r--r-- 1 mhorn staff 110956 16. Okt 18:56 base/libbase.a
>> -rw-r--r-- 1 mhorn staff 45876 16. Okt 18:56 engines/libengines.a
>>
>>
>> 0.12.x BRANCH , non-engine code:
>>
>> $ size */*.a | sort -nr | head
>> __TEXT __DATA __OBJC others dec hex
>> 87543 1180 0 0 88723 15a93
> graphics/libgraphics.a(hq3x_i386.o)
>> 65445 1204 0 0 66649 10459
> graphics/libgraphics.a(hq2x_i386.o)
>> 51949 160 0 370 52479 ccff
> gui/libgui.a(ThemeModern.o)
>> 38997 36 0 374 39407 99ef
> base/libbase.a(commandLine.o)
>> 32101 424 0 710 33235 81d3 gui/libgui.a(launcher.o)
>> 29182 296 0 341 29819 747b gui/libgui.a(options.o)
>> 28307 1700 0 354 30361 7699
> sound/libsound.a(audiostream.o)
>> 27710 84 0 269 28063 6d9f
> gui/libgui.a(theme-config.o)
>> 22040 120 0 462 22622 585e
> common/libcommon.a(advancedDetector.o)
>> 20945 160 0 249 21354 536a
> gui/libgui.a(ThemeClassic.o)
>>
>> $ ll -S */*.a
>> -rw-r--r-- 1 mhorn staff 594716 16. Okt 19:16 gui/libgui.a
>> -rw-r--r-- 1 mhorn staff 524604 16. Okt 19:16 graphics/libgraphics.a
>> -rw-r--r-- 1 mhorn staff 416684 16. Okt 19:16 sound/libsound.a
>> -rw-r--r-- 1 mhorn staff 267020 16. Okt 19:16 common/libcommon.a
>> -rw-r--r-- 1 mhorn staff 146228 16. Okt 19:16 backends/libbackends.a
>> -rw-r--r-- 1 mhorn staff 118244 16. Okt 19:16 base/libbase.a
>> -rw-r--r-- 1 mhorn staff 8608 16. Okt 19:16 engines/libengines.a
>>
>>
>> So, the HQx scalers are big, but they are desktop-only, so no problem.
>> But then, a very sizable chunk is taken by the new GUI code. The old
>> code was not tiny either, but it's clear that libgui.a and
>> libgraphis.a grew considerably (also libcommon.a grew, partially due
>> to the XML parser, but other changes are in there as well). It sure
>> would be nice to get those number back down a bit...
>>
>> However, take all these numbers with a big grain of salt: We use lots
>> of template code these days, and that causes the compiler to generate
>> certain chunks of code multiple times, put into each *.o file
>> separately. Only during linking time are these duplicates resolved and
>> removed. So, the actual contribution of those *.o files to the
>> resulting binary might be a lot less than what is listed above.
>>
>> On the other hand, this immediately hints at a potential way to save
>> memory: By carefully reconsidering how we use templates; esp. for the
>> container classes, we might be able to save some KB of duplicate code
>> (duplicate because the compiler generates it anew for each e.g.
>> HashMap variant, even though the code each time is almost or
>> completely identical). There are some ways to reduce that. If anybody
>> is interested in looking into that, talk to me.
>>
>>
>> Here's what I got for engines (I enabled all engines):
>>
>> TRUNK rev 34812, non-engine code:
>>
>> $ size engines/*/*.a | sort -nr | head
>> __TEXT __DATA __OBJC others dec hex
>> 98802 2924 0 546 102272 18f80
> engines/kyra/libkyra.a(staticres.o)
>> 77058 64 0 553 77675 12f6b
> engines/lure/liblure.a(hotspots.o)
>> 55721 244 0 351 56316 dbfc
> engines/touche/libtouche.a(touche.o)
>> 54580 2112 0 333 57025 dec1
> engines/kyra/libkyra.a(sound_towns.o)
>> 53776 29904 0 613 84293 14945
> engines/scumm/libscumm.a(detection.o)
>> 51834 48 0 532 52414 ccbe
> engines/kyra/libkyra.a(script_lok.o)
>> 51821 44 0 346 52211 cbf3
> engines/igor/libigor.a(igor.o)
>> 51025 96 0 719 51840 ca80
> engines/kyra/libkyra.a(script_hof.o)
>> 50265 0 0 320 50585 c599
> engines/drascula/libdrascula.a(animation.o)
>> 48901 256 0 509 49666 c202
> engines/drascula/libdrascula.a(rooms.o)
>>
>> To put this into perspective, here's the size of the lib*.a files for
>> each engine (to be taken with even more grains of salt, of course, but
>> they give a good rough indication anyway):
>> $ ll -S engines/*/*.a
>> -rw-r--r-- 1 mhorn staff 2661204 16. Okt 18:51 engines/scumm/libscumm.a
>> -rw-r--r-- 1 mhorn staff 1960012 16. Okt 18:53 engines/kyra/libkyra.a
>> -rw-r--r-- 1 mhorn staff 1027996 16. Okt 18:52 engines/gob/libgob.a
>> -rw-r--r-- 1 mhorn staff 877820 16. Okt 18:54 engines/parallaction/
>> libparallaction.a
>> -rw-r--r-- 1 mhorn staff 823140 16. Okt 18:51 engines/agos/libagos.a
>> -rw-r--r-- 1 mhorn staff 740188 16. Okt 18:55 engines/saga/libsaga.a
>>
>> [...]
>> -rw-r--r-- 1 mhorn staff 238412 16. Okt 18:54 engines/made/libmade.a
>>
>> 0.12.x BRANCH , non-engine code:
>>
>> $ size engines/*/*.a | sort -nr | head
>> 92384 3040 0 531 95955 176d3
> engines/kyra/libkyra.a(staticres.o)
>> 77074 64 0 553 77691 12f7b
> engines/lure/liblure.a(hotspots.o)
>> 57233 0 0 345 57578 e0ea
> engines/drascula/libdrascula.a(animation.o)
>> 55273 236 0 341 55850 da2a
> engines/touche/libtouche.a(touche.o)
>> 54956 2368 0 353 57677 e14d
> engines/kyra/libkyra.a(sound_towns.o)
>> 51882 48 0 532 52462 ccee
> engines/kyra/libkyra.a(script_lok.o)
>> 51854 36 0 346 52236 cc0c
> engines/igor/libigor.a(igor.o)
>> 51487 29832 0 558 81877 13fd5
> engines/scumm/libscumm.a(detection.o)
>> 50993 96 0 719 51808 ca60
> engines/kyra/libkyra.a(script_hof.o)
>> 49606 40 0 554 50200 c418
> engines/drascula/libdrascula.a(rooms.o)
>>
>> $ ll -S engines/*/*.a
>> -rw-r--r-- 1 mhorn staff 2690660 16. Okt 19:16 engines/scumm/libscumm.a
>> -rw-r--r-- 1 mhorn staff 1861188 16. Okt 19:16 engines/kyra/libkyra.a
>> -rw-r--r-- 1 mhorn staff 948060 16. Okt 19:16 engines/gob/libgob.a
>> -rw-r--r-- 1 mhorn staff 803404 16. Okt 19:16 engines/agos/libagos.a
>> -rw-r--r-- 1 mhorn staff 711500 16. Okt 19:16 engines/saga/libsaga.a
>> -rw-r--r-- 1 mhorn staff 696756 16. Okt 19:16 engines/parallaction/
>> libparallaction.a
>> [...]
>> -rw-r--r-- 1 mhorn staff 232492 16. Okt 19:16 engines/made/libmade.a
>>
>> So it seems most engines got a bit bigger, somehow... This might be
>> due to changes to our templated code in common, not sure yet.
>>
>> Cheers,
>> Max
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Scummvm-devel mailing list
>> Scummvm-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
> __________________________________________________
> Do You Yahoo!?
> En finir avec le spam? Yahoo! Mail vous offre la meilleure protection
> possible contre les messages non sollicités
> http://mail.yahoo.fr Yahoo! Mail
More information about the Scummvm-devel
mailing list