[Scummvm-devel] Code size
Vicent Marti
tanoku at gmail.com
Sat Oct 18 16:31:14 CEST 2008
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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minimal_vector_renderer.diff
Type: application/octet-stream
Size: 20173 bytes
Desc: not available
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20081018/2031a7a5/attachment.obj>
More information about the Scummvm-devel
mailing list