Binaire grootte minimalisen

[Verwijderd]

Beste Tweakers,

Ik tracht een executable zo klein mogelijk te krijgen, maar weet niet goed waar te beginnen. Uiteraard gebruik ik compilerinstellingen die de grootte optimaliseren, maar dit heeft niet zo veel effect. Ik zou eigenlijk in de eerste plaats een overzicht willen van waar de 'code bloat' zich eigenlijk bevindt. Bestaan daar specifieke tools voor?

Als ik een overzicht had van welke functies, klassen en/of (statische) data het meeste plaats innemen zou ik misschien tot nieuwe inzichten kunnen komen.

Hartelijk dank!

[GeniusJennis]

Om 3:13 snachts krijg je hier geen zinnig antwoord op, zoals je ziet....
Nee, om 3:13 dit soort onzinnige opmerkingen plaatsen; dat schiet op

[ Voor 39% gewijzigd door RobIII op 21-11-2008 03:35 ]

[RobIII]

Kijk eens naar UPX
Kort: Daarmee pak je een executable in, zonder afhankelijk te zijn van extractors als winzip/winrar e.d. en blijft je executable dus gewoon executable en (haast) onmerkbaar gedecomprimeerd.

Waarom wil je de .exe zo klein mogelijk hebben? Is het een excessief groot bestand? Voor download mogelijkheden? Beperkte opslagruimte? Wat?

[ Voor 22% gewijzigd door RobIII op 21-11-2008 03:43 ]

[Verwijderd]

RobIII schreef op vrijdag 21 november 2008 @ 03:34:
Kijk eens naar UPX
...
Waarom wil je de .exe zo klein mogelijk hebben?

UPX kende ik al, maar helpt niet echt in mijn situatie. Mijn software wordt onderdeel van een groter geheel voor een klant die een 'quotum' heeft opgelegd om de downloadgrootte te beperken. De download zelf is al sterk gecomprimeerd dus UPX maakt het verschil niet.

Mijn binary is momenteel zo'n 4 MB en dat is "excessief groot" voor m'n klant. Het moet zeker onder de 1 MB en liefst nog veel kleiner. M'n klant begrijpt dat dit een grote eis is maar is bereid om features te laten vallen die te groot zijn. Maar dan moeten we eerst weten waar precies die 4 MB uit bestaat.

Ik heb zelf het vermoeden dat er wat code bloat is die te vermijden valt. Zo kan een template class vaak veel code genereren en door van de parameters variabelen te maken kan dat gereduceerd worden. Maar ik kan niet in het wilde weg maar wat proberen, daar is m'n project te groot voor.

Enige tool of systematische aanpak om dit te vergemakkelijken zou dus enorm nuttig zijn.

[Xiphalon]

Je compileert uiteraard toch wel zonder debug informatie?

Wat je zou kunnen doen is de linker-map doorspitten, maar het hangt van je compiler af of daar handige info in staat. Hopelijk staat er per methode danwel source-file een grootte in qua gecompileerde bytes.

[Boudewijn]

-Os compiler flag in GNU, maar dan voor jouw compiler?

[ZaZ]

Compileer je een runtime mee? Anders zou je die ook eenmalig kunnen distribueren en zijn de updates een stuk kleiner. Aan de grootte van je .obj files kun je al zien welke gedeeltes van je code het 'grootst' zijn.
Heb je toevallig geen grote resources? Kijk naar je includes. Welke taal/omgeving? Zo kun je bijv als je Delphi gebruikt, ook gebruik maken van KOL als je bereid bent wat van je RAD functionaliteit in te leveren.
Maar goed... dit blijft raden zo.

[D-Raven]

offtopic:
Ik ben eigenlijk wel benieuwd naar wat de achterliggende reden is waarom je klant 4MB excessief groot vindt.
Moet het op een floppy passen ofzo ?

[matthijsln]

Verwijderd schreef op vrijdag 21 november 2008 @ 02:41:
Als ik een overzicht had van welke functies, klassen en/of (statische) data het meeste plaats innemen zou ik misschien tot nieuwe inzichten kunnen komen.

Hartelijk dank!

Blijkbaar gebruik je c++, misschien kan je linker een mapfile genereren met alle functies erin.

Daarnaast zijn de gebruikelijke trucs:
- gebruik de dll versie van de stdlib (msvcrt.dll)
- merge .text en .code secties
- gebruik het minimum alignment (4k)
- gebruik helemaal geen stdlibs

[Janoz]

Het lijkt me handig wanneer c0d1f1ed aangeeft welke taal en welk platform hij gebruikt ipv dat we meoten gokken dat het om c++ gaat.

[Boudewijn]

matthijsln schreef op vrijdag 21 november 2008 @ 10:11:
[...]

Blijkbaar gebruik je c++, misschien kan je linker een mapfile genereren met alle functies erin.

Daarnaast zijn de gebruikelijke trucs:
- gebruik de dll versie van de stdlib (msvcrt.dll)
- merge .text en .code secties
- gebruik het minimum alignment (4k)
- gebruik helemaal geen stdlibs

Waarom denk je dat hij C++ gebruikt?
En waarom denk je dat hij windows heeft, dude?

[matthijsln]

Boudewijn schreef op vrijdag 21 november 2008 @ 10:29:
[...]

Waarom denk je dat hij C++ gebruikt?
En waarom denk je dat hij windows heeft, dude?

Nou "dude", hij heeft het over template classes en een compiler. En inderdaad, zijn klant is blijkbaar TransGaming dus misschien gaat het niet over Windows... Maar ja het blijft gokken als hij dat er niet bijzet he.

[curry684]

D-Raven schreef op vrijdag 21 november 2008 @ 09:46:

offtopic:
Ik ben eigenlijk wel benieuwd naar wat de achterliggende reden is waarom je klant 4MB excessief groot vindt.
Moet het op een floppy passen ofzo ?

4MB is voor een executable ook fors lomp hoor, of het nu VB6, C++, C#, Java of wat dan ook is

Als je met templates overigens 4MB aan code kunt genereren ben je ook wel briljant bezig - code loopt niet zo snel op. Je zit dan met een debugbuild oftewel met stapels spannende data zoals geile jpeg'jes om je windows te decoreren.

[ Voor 23% gewijzigd door curry684 op 21-11-2008 11:01 ]

[Zoijar]

Je zal wel libraries statisch mee linken (ipv als dll/so), kijk daar eerst naar.

[Verwijderd]

Om even alle twijfel weg te nemen: Ik gebruik C++ en de Visual Studio 2005 compiler, op Windows. Heel erg relevant is dat niet denk ik; het is niet uitgesloten dat de software ooit op een ander platform moet draaien en met een andere compiler.

Ik ben dus vooral op zoek naar 'duurzame' code size optimalisaties. En de eerste stap lijkt mij om te bepalen waar al die megabytes vandaan komen zodat ik weet waar ik mij op kan concentreren. Beetje een vage vraak, ik weet het, maar dat is net mijn probleem ik weet niet goed waar te beginnen ookal ben ik er van overtuigd dat er veel potentieel is om de code kleiner te maken.

Een soort profiler zou ideaal zijn. Niet een die de prestaties meet maar een die me een overzichtelijk beeld geeft van de code bloat.

[Verwijderd]

darkmage schreef op vrijdag 21 november 2008 @ 09:15:
Je compileert uiteraard toch wel zonder debug informatie?

Debug build is 13 MB. Die 4 MB is echt al met een zorgvuldige selectie optimalisaties van zowel compiler als linker.

Wat je zou kunnen doen is de linker-map doorspitten, maar het hangt van je compiler af of daar handige info in staat. Hopelijk staat er per methode danwel source-file een grootte in qua gecompileerde bytes.

Ja, da's al een mooi begin! VC++ genereert een .map waarbij de beginpostie van elke functie (of statische variabele) binnen de executable aangeduid staat. Door dus telkens het verschil te berekenen met de volgende functie krijg ik in principe de grootte. Ook het sourcebestand wordt vermeld en uit de (volledige) functienaam zou ik de C++ klasse kunnen halen. Zijn hier eventueel bestaande tools voor?

[Verwijderd]

matthijsln schreef op vrijdag 21 november 2008 @ 10:11:
- merge .text en .code secties

Klinkt interessant. Wat zijn de gevolgen hiervan (positief en negatief)?

- gebruik het minimum alignment (4k)

Ik geloof dat dit overeenkomt met het uitschakelen van 'Optimize for Windows 98'? Dat had ik al gedaan en dat leverde -10% op geloof ik.

- gebruik helemaal geen stdlibs

Aangezien enkel de gebruikte functies gelinkt worden en ik er niet te zwaar op steun vraag ik mij af of dit wel de moeite kan lonen? Ik moet dan zowiezo alternatieven implementeren en die moeten dan al kleiner zijn.

[Verwijderd]

D-Raven schreef op vrijdag 21 november 2008 @ 09:46:

offtopic:
Ik ben eigenlijk wel benieuwd naar wat de achterliggende reden is waarom je klant 4MB excessief groot vindt.
Moet het op een floppy passen ofzo ?

Ok, wat basic info kan geen kwaad denk ik... De klant is geïnteresseerd in SwiftShader als fallback voor 3D-ondersteuning. Voor wie een niet zo oude grafische kaart heeft wordt dat dus niet gebruikt en dan is 4 MB toch wel groot. Het product van de klant is op zich al niet groot maar moet op eender welke internetverbinding vlot binnen te halen zijn. Heel wat functionaliteit zal uiteindelijk niet nodig zijn maar voor we beginnen te snoeien zou het handig zijn een goed beeld te hebben van wat elke feature aan grootte kost zodat we een nuttige afweging kunnen maken.

[farlane]

Misschien toch maar even uitzoeken waarom je .exe 4MB is: mijn gok is dat je of resources meeneemt of libs statisch staat te linken.

[Verwijderd]

curry684 schreef op vrijdag 21 november 2008 @ 10:59:
Als je met templates overigens 4MB aan code kunt genereren ben je ook wel briljant bezig - code loopt niet zo snel op. Je zit dan met een debugbuild oftewel met stapels spannende data zoals geile jpeg'jes om je windows te decoreren.

Met templates kan je toch gekke dingen uithalen hoor. Neem bijvoorbeeld Boost::Spirit, waarmee je in een paar lijnen code een hele parser kan maken. Het gebruik van templates zorgt ervoor dat de compiler de gehele parse-tree genereert. Als je echter enkel een bestandspad wil parsen of zo gebruik je veel compacte lus of zo!

Soit, het is enkel binaire code in de vorm van een DLL, geen resources of andere vormen van multimedia. Er is 16 MB aan broncode dus dat het een binary van 4 MB oplevert is niet zo ongewoon. Tot nu toe was dat geen echt probleem maar deze klant wil best wat features (en prestaties) opofferen om dat sterk gereduceert te zien. Maar dan moeten eerst en vooral de trade-offs gekend zijn.

[Verwijderd]

farlane schreef op vrijdag 21 november 2008 @ 16:41:
Misschien toch maar even uitzoeken waarom je .exe 4MB is...

Proficiat, u heeft de vraag begrepen.

mijn gok is dat je of resources meeneemt of libs statisch staat te linken.

Geen resources, maar wel statische libraries. Dat laatste is nodig aangezien de eindgebruiks niet altijd de juiste versie hebben en we DLL hell willen vermijden. Ik geloof niet echt dat dit de bulk van 4 MB kan uitmaken, maar ik zal het toch eens testen om te zien wat het oplevert...

[RobIII]

Wil je even acht slaan op 't volgende a.u.b? topickick binnen 24 uur. We hebben een hele mooie -knop Ik zie je nu meermalen achter elkaar posten (4x en 2x) en dat is niet de bedoeling.

[ Voor 34% gewijzigd door RobIII op 21-11-2008 17:32 ]

[Verwijderd]

RobIII schreef op vrijdag 21 november 2008 @ 17:30:
Wil je even acht slaan op 't volgende a.u.b? topickick binnen 24 uur. We hebben een hele mooie [afbeelding]-knop Ik zie je nu meermalen achter elkaar posten (4x en 2x) en dat is niet de bedoeling.

Ah, geen probleem, ik vond het makkelijker en duidelijker afgelijnd door op iedereen afzonderlijk te antwoorden maar als dat een probleem is wil ik het best anders proberen.

[H!GHGuY]

Om eerlijk te zijn denk ik dat je uit 16MB code -> 4MB binary weinig gratis winst zal kunnen halen.

Begin even bij wat ZaZ zegt: bekijk de groottes van elk van je .obj files.
Dan zie je meteen welke stukken code veel plaats innemen en kun je op source file niveau wat gaan spitten.

Bovendien kun je dan proberen om mbv "#ifdef USE_FEATURE_X" constructies bepaalde features, waarvan je vermoedt (adhv de .obj files) dat ze veel plaats innemen, te strippen.

[MSalters]

Verwijderd schreef op vrijdag 21 november 2008 @ 16:47:
Geen resources, maar wel statische libraries. Dat laatste is nodig aangezien de eindgebruiks niet altijd de juiste versie hebben en we DLL hell willen vermijden.

Ik denk dat je eerlijk moet zijn ten opzichte van jezelf. DLL hell is niet zo erg als het klinkt. Miljoenen programmeurs konden er in de Windows 95 tijd mee leven. Je hebt nog steeds dezeflde draconische geheugenlimieten, dus accepteer ook die tradeoffs.

Kortom, gebruik de VC6 CRT die altijd aanwezig is. 0 bytes in je installer.

[Verwijderd]

Verwijderd schreef op vrijdag 21 november 2008 @ 09:05:
UPX kende ik al, maar helpt niet echt in mijn situatie. Mijn software wordt onderdeel van een groter geheel voor een klant die een 'quotum' heeft opgelegd om de downloadgrootte te beperken. De download zelf is al sterk gecomprimeerd dus UPX maakt het verschil niet.

Verkijk je daar niet op! Een dik 13mb applicatie (Win32 Delphi) wordt hier gezipt zo'n 5.5mb, en met UPX 3.3mb...

[Zoijar]

Ik snap dat het een eis van een klant is, maar ik blijf het toch een beetje een stenentijdperkeis vinden om een programma van 4MB terug te moeten brengen naar 1MB, zelfs door functionaliteit te verwijderen, alleen om download snelheden te bevorderen. Zo'n beetje de langzaamste internet verbinding hier op het moment is toch als snel 3Mb/s; dat doet zelfs de iphone en de allergoedkoopste internet abbos bij elke provider. We hebben het dan over een downloadtijd van 11 seconden terug brengen naar 4 seconden. Maarja, als het moet dan moet het maar, ik snap dat je er niets aan kan doen verder.

Verwijderd schreef op vrijdag 21 november 2008 @ 21:04:
Verkijk je daar niet op! Een dik 13mb applicatie (Win32 Delphi) wordt hier gezipt zo'n 5.5mb, en met UPX 3.3mb...

Vreemd verhaal. Winzip lossless compressie is vrij ideaal; het kan misschien wel iets beter, maar niet bijna 2x kleiner.

[ Voor 22% gewijzigd door Zoijar op 21-11-2008 21:11 ]

[matthijsln]

Verwijderd schreef op vrijdag 21 november 2008 @ 15:57:
[...]
Klinkt interessant. Wat zijn de gevolgen hiervan (positief en negatief)?

Door mergen heb je geen extra padding tussen de secties nodig, dus een kleinere executable. Alhoewel dit voor een trucje is uit de tijd dat ik 4k en 64k exe's aan het brouwen was. Hoeveel dit op meerdere megabyte executables effect heeft betwijfel ik...

De link optie is /merge, bijvoorbeeld:
/merge:.data=.text /merge:.rdata=.text (hangt een beetje af van hoe je secties nu heten, gebruik dumpbin)
en om je sectie wel executable te maken:
/section:.text,erw

Kijk hier voor de linker options...

Ik geloof dat dit overeenkomt met het uitschakelen van 'Optimize for Windows 98'? Dat had ik al gedaan en dat leverde -10% op geloof ik.

Volgens de help voor /OPT:WIN98 indd wel, je kan nog even expliciet /align:4096 toevoegen om te kijken of het nog verschil maakt.

Aangezien enkel de gebruikte functies gelinkt worden en ik er niet te zwaar op steun vraag ik mij af of dit wel de moeite kan lonen? Ik moet dan zowiezo alternatieven implementeren en die moeten dan al kleiner zijn.

Het is makkelijker om kleine executables te maken wanneer je klein kan beginnen

Dit is een oud voorbeeld van een 1k exe die bijna niks doet, maar hij is wel klein. Als je hier telkens code aan toevoegt
- die zoveel mogelijk msvcrt.dll functies gebruikt (die dll is standaard op win95!)
- welke zo min mogelijk statische libs gebruikt
- voor je gui geen dikke libs gebruikt maar bv gewoon dialog boxes (kleine resources)
- die je textures en modellen procedureel genereert
- welke geen onnodig veel resources include (splash screens, etc.)
Zou je exe alleen moeten groeien met de grootte van je object files.

Dat is uiteraard lastig als je applicatie zwaar leunt op een GUI library of graphics library met weer een boel dependencies. Maar vaak genoeg kan een applicatie een stuk kleiner gemaakt worden door overbodige troep te verwijderen.

Alhoewel je zoals anderen zeggen je wel kan afvragen wat voor zin het nog heeft. Aan de andere kant, kijk eens waarom μTorrent mede zo populair is geworden: heel kleine exe grootte en dus snelle download. Er hangt gewoon een stigma aan grote downloads dat het bloatware is. Kleine apps zijn snel Uiteraard kan het best omgekeerd zijn, maar dat is wel het beeld wat veel gebruikers hebben denk ik. Ik begrijp de eis daarom ook wel...

[RobIII]

Zoijar schreef op vrijdag 21 november 2008 @ 21:07:
Vreemd verhaal. Winzip lossless compressie is vrij ideaal; het kan misschien wel iets beter, maar niet bijna 2x kleiner.

Nu ben ik geen kenner op dat gebied, dus misschien verkoop ik onzin; maar (Win)Zip en consorten zijn natuurlijk generieke compressiealgoritmes en UPX is er puur op gebouwd executables te comprimeren. Met de juiste kennis van een executable kun je daar natuurlijk bepaalde optimalisaties voor inbouwen.

[Comp_Lex]

Statische libs is meestal een zeer goede reden waarom een executable enorm groot wordt. Ik maak zelf gebruik van wxWidgets libs en die zijn static gelinked met mijn sourcecode.

Executable grootte
---------------------------

Static: 2.5 MB
Dynamic: (hooguit) 100 KB

[MLM]

je kan wat kleine "simpele" grootte optimalisaties doen door je linkerinstellingen te tweaken. Merge bijvoorbeeld de .text en .data secties, maak de executable fixed (geen relocationtable).

Als je geen dynamic_cast en/of C++ exceptions gebruikt, disable dan RTTI in je compilersettings.

Vergeet niet dat code zoals dit:

C++:

void foo
{
   static char buf[1000];  //1000 bytes in je image
   sprintf(buf, "whatever");
}

meer plaats in neemt

C++:

void foo
{
  static char *buf = 0; //4 bytes in je image
  if(!buf) buf = new char[1000]; //1000 bytes op de heap at runtime
  sprintf(buf, "whatever");
}

(Volgens mij word dit SOMS gefold door de compiler, maar ik ben niet zeker. Natuurlijk is dit een far-fetched geval (je kan buf op de stack gooien), maar mijn punt is, zoek naar grote arrays of iets dergelijks die je .data or .rdata section erg groot maken, en OF initialiseer die dynamically, of prop het in een datafile en lees het in (het gaat om de executablesize immers)

[ Voor 17% gewijzigd door MLM op 22-11-2008 14:00 ]

[Verwijderd]

Zoijar schreef op vrijdag 21 november 2008 @ 21:07:
Vreemd verhaal. Winzip lossless compressie is vrij ideaal; het kan misschien wel iets beter, maar niet bijna 2x kleiner.

Getest met de ingebouwde zipper in XP, niet met WinZip...

[Soultaker]

Sowieso is deflate (waar standaard zip op neerkomt) verre van ideaal vergeleken met alle toepassingsspecifieke filters die UPX toepast (en andere binary packers zoals LZMA ook doen). Het verbaast me niets dat een tool die expliciet gemaakt is om executable code te comprimeren daarbij fors beter presteert.

[Zoijar]

RobIII schreef op vrijdag 21 november 2008 @ 23:22:
Nu ben ik geen kenner op dat gebied, dus misschien verkoop ik onzin; maar (Win)Zip en consorten zijn natuurlijk generieke compressiealgoritmes en UPX is er puur op gebouwd executables te comprimeren. Met de juiste kennis van een executable kun je daar natuurlijk bepaalde optimalisaties voor inbouwen.

Ik ben ook zeker geen expert, maar bij lossless compressie heb je te maken met theoretische entropie grenzen. Winzip zit daar gewoon al redelijk dicht tegenaan, en in dat geval is het gewoon theoretisch onmogelijk om het bv nog 2x zo klein te krijgen. Een goede lossless compressor ziet al die patronen automatisch al. Misschien dat het met een aantal slimme, aggresieve optimalisaties een x-aantal procent beter kan in specifieke gevallen, maar dan houdt het wel op.

Ik heb het ook even getest, met een 1.2MB windows executable van mezelf. Winzip geeft een 521KB file, en upx op de hoogste setting een 503KB file. Dat is redelijk, het scheelt idd een paar procent. Maar als je je file toch al compressed ter download aanbiedt, dan heeft upx echt bijzonder weinig nut.

[MLM]

vergeet niet dat UPX bepaalde optimalisaties kan doorvoeren die WinZip niet kan, doordat het bepaalde informatie uit de .exe gewoon achterwege laat omdat die niet strict noodzakelijk zijn om de image te draaien. UPX gebruikt intern LZO compressie, die niet specifiek voor binaries is. LZO is vooral "bekend" door de extreem snelle in-place uitpak methode en best redelijke compressieratio.

Aan de andere kant: Vergeet ook niet dat UPX compressed file ook nog de "unzipper" bevat (niet echt bijzonder groot, een paar KB), dus dat voordeel heeft WinZip weer mee

In elk geval is het niet veel moeite om beide te proberen, en de beste te kiezen, maar hoe dan ook gaat UPX noch WinZip op magische wijze een slecht geprogrammeerde binary kunnen verkleinen. (Ik ga daar hier maar vanuit, want anders is het gewoon onmogelijk om de binary kleiner te maken).

Als sidenote, je kan een eventuele niet technisch onderlegd persoon foppen door je binary in meerdere DLL's oid te splitsen, die allemaal kleiner dan 1 MB zijn

[phobosdeimos]

Alles herschrijven in python, kan je gewoon broncode afleveren, dat comprimeert als een tierelier

[Verwijderd]

[Warning: Dit antwoord is misschien n00bish]

Waarschijnlijk doet je compiler dit zelf wel. Maar je kan kijken of je FileAlignment niet kan verkleinen?
Ik denk dat ik ook eens ergens heb gelezen dat je uit je DOS-stub alles kan nullen buiten e_magic en e_lfanew. (Zoek een goede PE editor!)

Edit:
@ MLM. Ik had een amateuristisch gebouwde Delphi executable en heb die met UPX toch van 451 naar 168kb gekregen. Maar voor de rest niets qua compressie meegegeven.

[ Voor 23% gewijzigd door Verwijderd op 23-11-2008 18:44 ]

[MLM]

in de praktijk kan je de DOS stub wel weghalen ja (praktisch niemand draait meer 16 bits OS), maar dat is ook echt 1KB oid, dat gaat niet echt helpen

en tuurlijk, UPX is een prima tool die best redelijke compressie kan doen, maar het is geen magische tool die van 4MB 1MB gaat maken. (sure, die ratio is te doen op kleine binaries, omdat je dan net zoveel headers/tables/overige info die some voor 50% uit nullen bestaat) hebt als daadwerkelijke code)

de TS moet gewoon in zijn code gaan kijken om dit op te lossen, en als dat het niet oplost omdat je series 4MB compiled code hebt (dat kan best), dan gaat het gewoon niet 1 MB worden ik snap de 1MB limit ook niet echt, mss is het verstandig om de opdrachtgever te vragen die limiet op te hogen ofzo :x

[Elijan9]

Qua functionaliteit is de 4Mb helemaal niet zoveel, voor een complete software 3D renderer... Ik vind dat je klant zeurt...

Compileer minimaal voor Pentium III, dat werkt op alle moderne processoren en kan ook wel eens wat winst opleveren (in de orde van 1% tot 10%), omdat er dan kortere instructies gekozen kunnen worden.
En als je geen RTTI nodig hebt dan kan je wel wat winst behalen door de ondersteuning hiervoor uit te zetten.

Verder/daarbij inderdaad optimaliseren voor size en alles wat matthijsln al adviseerde...

Wat ook vaak helpt: de klant tactisch uitleggen dat jullie dit kunnen realiseren voor de klant, maar dat zij de enige klant zijn die dit graag zo ziet en dat jullie daarom een hoop klantspecifieke wijzigingen moeten doorvoeren en dat daar dus wel een hoger prijskaartje tegenover staat...

Maar alle pakketten die iets doen met 3D (games, CAD, etc) zijn tegenwoordig in verhouding toch wel veel groter dan 4Mb?

[MLM]

een simpele 3D software renderer past wel in 100KB hoor (ik heb er 1 gemaakt), maar hoe ingewikkelder je het wilt maken, hoe meer codepaths je nodig hebt, en hoe meer code er gecompiled zal worden

over het algemeen kan je zeggen dat de hoeveelheid data die je in 3D paketten verwerkt ENORM is, maar de code op zich niet zo groot.

misschien dat je kan proberen om de Intel compiler er op los te laten, die kan soms andere resultaten geven, hoewel ik niet denk dat die op magische wijze je binary gaat laten krimpen

[Verwijderd]

Of, zoals ik al zei, eens kijken of je FileAlignment niet kan verkleinen. Als je deze 100kb kan verkleinen, ben je per sectie weer 100kb kwijt. je zal hier geen Mb's mee halen, maar alle beetjes helpen.

[Verwijderd]

Bedankt allemaal voor de ideeën! Vooral het analyseren van het .map bestand bracht wat overbodige afhankelijkheden aan het licht en geeft een idee van wat er gewonnen kan worden door bepaalde features te laten vallen.

Ik vermoed dat tools voor code coverage ook van grote hulp kunnen zijn. Die kunnen mij tonen welke functies niet gebruikt worden bij een bepaalde testrun...