|
This is what some hacker wrote back about my software that I used this in:
me:
If your 30 day trial runs out and you want to test a newer version,
let me know and I'll send you a temporary license code.
HACK:
Ok, though it would be easier just to crack it.
HACK:
Out of curiosity, your application has some "flaws" which make running
a disassembler difficult (haven't really bothered trying too hard;
dead-listing is not my style). Was that delibrate, or just a side
effect of whatever compiler you use?
me:
snicker snicker
|
|
|
|
|
To get a small exe in .NET add "/filealign:16 /align:16" to the linker command line in your release project.
[]'s
Richard Natal
--< Rick-SP >--
Join to the best... Join to C++ developers
|
|
|
|
|
I tried to combine Pietrek's code with AggressiveOptimize.h
http://msdn.microsoft.com/msdnmag/issues/01/01/hood/
I inserted the
<br />
#include "AggressiveOptimize.h"<br />
as the first to each cpp, and then:
<br />
nmake -f libctiny.mak<br />
cl hello.cpp libctiny.lib<br />
del *.obj<br />
The result -- EXE is the same (2.5 K), I can even see a .TEXT section with DUMPBIN.
<br />
Dump of file hello.exe<br />
Summary<br />
1000 .data<br />
1000 .rdata<br />
1000 .text<br />
What am I doing wrong?
Thanks.
|
|
|
|
|
Works great, I wasn't concerned with size but rather with execution speed. My software performs several computational intensive tasks, mainly image processing algorithms. I managed to shave off 30ms of execution time which brings it close to a real-time behaviour, and this is a big improvement for me. Thanks
Marius
|
|
|
|
|
Generally, if this is happening, then the algorithm you're using is packing-sensitive - in other words, the instructions in the loop are all fitting within the CPU's cache, and a change in a totally unrelated section of code might cause the address of this bit of code to shift, making it NOT pack better. Not to mention that a different CPU stepping might cause slightly different results.
You might want to spend the time profiling your code and hand-tuning it, and even consider manipulating some of it in raw assembly. Intel offers their VTune product as a 30-day eval, and while I'm not thrilled with what they tout it for, the only feature I found useful was a line-by-line display of execution time, so you can see how fast specific lines of code run and where to massage it at.
"I was in a computer game. Funny as hell, it was the most horrible thing I could think of."
|
|
|
|
|
Works great, I wasn't concerned with size but rather with execution speed. My software performs serveral computational intensive tasks, mainly image processing algorithms. I managed to shave of 30ms of execution time which brings it close to a real-time behaviour, and this is a big improvement for me. Thanks
Marius
|
|
|
|
|
Very easy to impliment and has resulted in substantial gains for my project. I have many DLLs that were averaging 20KB-72KB (average having already had some .exe reducing tips applied to them). The larger DLLs (where there was actually a substancial amount of code and API calls) were reduced by about 20% in size, and some of the samller ones (resource libraries and such) to 3 or 4KB! This is exactly what I have been searching for, very good work!
I haven't done any testing to see if any of this reduces RAM use, but a quick glance at the mem usuage output suggests some small savings there too.
|
|
|
|
|
I tested your header with cximage[^], the result is -10% in disk space and -15% in memory.
It's a good result, but far from the 25% of your reports. 5 stars anyway
|
|
|
|
|
Often overlooked - For more info on the subject, check out the 'Under the hood' articel by Matt Pietrek (http://msdn.microsoft.com/msdnmag/issues/01/01/hood/default.aspx)
|
|
|
|
|
|
This is from a REAL WORLD project that is SHIPPING to our customers. It's a large project with lots of database usage, that runs within a mixed 95/98/me/xp/2k/xyz setting. This is from an excel spreadsheet; the filenames have been changed for NDA reasons.
These results are 100% reproducable - please, if you are confused about if this works for you or not, first do your own benchmarks and then post them! Hey, let's have a compitition - who can get the most savings?
NOTE: dunno how well this is going to paste in here..... I can email the orignal XLS file if anyone wants it...
Optmized with header: Without header: Savings % smaller
Size (Bytes) Filename Size (Bytes) Filename
"199,168" AdminDB.dll "262,144" AdminDB.dll "62,976" 24.02%
"185,344" AdminGUI.dll "221,184" AdminGUI.dll "35,840" 16.20%
"114,176" BillingGUI.dll "151,552" BillingGUI.dll "37,376" 24.66%
"62,976" CalendarDB.dll "86,016" CalendarDB.dll "23,040" 26.79%
"137,216" CalendarGUI.dll "167,936" CalendarGUI.dll "30,720" 18.29%
"138,240" ConditionalsDB.dll "176,128" ConditionalsDB.dll "37,888" 21.51%
"198,144" ConditionalsGUI.dll "241,664" ConditionalsGUI.dll "43,520" 18.01%
"111,616" ContactsGUI.dll "143,360" ContactsGUI.dll "31,744" 22.14%
"60,928" EMailDB.dll "86,016" EMailDB.dll "25,088" 29.17%
"117,248" EMailGUI.dll "151,552" EMailGUI.dll "34,304" 22.64%
"88,576" CoreBase.dll "122,880" CoreBase.dll "34,304" 27.92%
"328,192" CoreControls.dll "401,408" CoreControls.dll "73,216" 18.24%
"128,000" CoreDBMgr.dll "184,320" CoreDBMgr.dll "56,320" 30.56%
"110,592" CoreDialogs.dll "135,168" CoreDialogs.dll "24,576" 18.18%
"307,712" CoreToolkit.dll "389,120" CoreToolkit.dll "81,408" 20.92%
"110,592" Client.exe "126,976" Client.exe "16,384" 12.90%
"431,104" ClientComponents.dll "561,152" ClientComponents.dll "130,048" 23.18%
"14,336" ClientDBMgr.dll "28,672" ClientDBMgr.dll "14,336" 50.00%
"367,616" ClientDialogs.dll "454,656" ClientDialogs.dll "87,040" 19.14%
"22,016" ClientToolkit.dll "36,864" ClientToolkit.dll "14,848" 40.28%
"230,400" HoldingsDB.dll "290,816" HoldingsDB.dll "60,416" 20.77%
"511,488" HoldingsGUI.dll "651,264" HoldingsGUI.dll "139,776" 21.46%
"77,312" FolderListGUI.dll "94,208" FolderListGUI.dll "16,896" 17.93%
"282,112" OrdersDB.dll "364,544" OrdersDB.dll "82,432" 22.61%
"120,832" OrdersGUI.dll "147,456" OrdersGUI.dll "26,624" 18.06%
"23,040" SystemNotificationsDB.dll "36,864" SystemNotificationsDB.dll "13,824" 37.50%
"85,504" TaskDB.dll "114,688" TaskDB.dll "29,184" 25.45%
"71,168" TaskGUI.dll "94,208" TaskGUI.dll "23,040" 24.46%
"6,144" TitleDB.dll "24,576" TitleDB.dll "18,432" 75.00%
"49,152" TitleGUI.dll "69,632" TitleGUI.dll "20,480" 29.41%
"229,376" Services.exe "229,376" Services.exe 0 0.00%
"20,480" ServicesNTLoader.exe "20,480" ServicesNTLoader.exe 0 0.00%
"77,824" PDFout.dll "77,824" PDFout.dll 0 0.00%
"5,018,624 bytes in 33 files and 2 dirs" "6,344,704 bytes in 33 files and 2 dirs" 1326080 25.91%
"5,079,040 bytes allocated" "6,352,896 bytes allocated" Average savings
Slop: "60,416" (118 512-byte clusters) "8,192" (16 512-byte clusters)
Visual Studio Favorites - improve your development!
GUIgui - skin your apps without XP
|
|
|
|
|
Almost forgot. Compressed sizes, using WinZip, Maximum compression:
Optmized.zip - 1.73 MB (1,822,928 bytes) on disk: 1.74 MB (1,826,816 bytes)
Unoptimized.zip - 2.01 MB (2,110,334 bytes) on disk: 2.01 MB (2,113,536 bytes)
Visual Studio Favorites - improve your development!
GUIgui - skin your apps without XP
|
|
|
|
|
OK, that's what I say very specific cases. Most of you components are about 40-50 K and surely this will help in this case. Please read my reponse to Tim Kosse in the thread below.
And, please, please do not take this as an offense. I may be rude in the beginning but I apologize for that. I just wanted to write my opinions. I did not mean to insult, or ..etc. And please continue writing more articles. This kind of comments should not dicourage you. This tip may not be helpful for me; but it may be very useful for somebody else.
Mustafa Demirhan
http://www.macroangel.com
Sonork ID 100.9935:zoltrix
<nobr>They say I'm lazy but it takes all my time
|
|
|
|
|
If it did not help for you, perhaps you could post your results. It would be interesting to see more metrics than just the projects me and the others are using with it.
Visual Studio Favorites - improve your development!
GUIgui - skin your apps without XP
|
|
|
|
|
Todd C. Wilson wrote:
If it did not help for you, perhaps you could post your results. It would be interesting to see more metrics than just the projects me and the others are using with it.
Well, you did not get my point: I did not say that it does not help. It is just a very very very small reduction in the size. Nothing else!!!
But just FYI, here are the results for one of my projects:
Original .exe Size (without using the library): 4,112,483 bytes
Size after optimization: 4,104,291 bytes
Gain = 8,192 Bytes
Gain in percentage = 0.199%
Apart from the exe file, the project has 7 DLL files. All of the files have similar gains. So totally:
The total size of the project before optimization: 7,626,752 bytes
The total size after optimization: 7,553,024 bytes
Total Gain = 73,728 bytes
Total Gain in percentage: 0.96%
As you see, in a real project the gain will be less than 1%. Also, this will be the case for most of the applications not your example. So tell me: Who cares about this 1% reduction in size?
Mustafa Demirhan
http://www.macroangel.com
Sonork ID 100.9935:zoltrix
<nobr>They say I'm lazy but it takes all my time
|
|
|
|
|
Mustafa Demirhan wrote:
As you see, in a real project the gain will be less than 1%. Also, this will be the case for most of the applications not your example. So tell me: Who cares about this 1% reduction in size?
I would suspect that you have already changed a lot of your compiler settings for this project, so what the header is doing, you've already done. If you read the article and the header, you'll notice that I mention that instead of farting around with the settings for each project, the header does it for you. If you wish to post your project's C++ options settings, we can see what you've done already do it. You might want to try resetting your project back to the default and compile it again without this header and see what it does.
As for this being a real project or not, I have no idea what your project is or what it is doing. However, the projects I usually work on are corporate enterprise deliverables, and are much larger than a single exe and seven dlls. FYI, the real-world project that I gave as an example is used world wide by a Well Known Corporation, which is why I had to change the names to protect the NDA.
Also, as mentioned, your milage may vary - nobody is forcing you to use this thing, but a lot of people have, and it has always helped. You seem to be more pissed off about the fact that it doesn't make your program super-spiffy, and only gives you 73k of savings - this I would chalk up to more of your OWN optimization settings more than anything else. You're trying to place "blame" for something where you've already done most of the same work!
Visual Studio Favorites - improve your development!
GUIgui - skin your apps without XP
|
|
|
|
|
Here is another benchmark:
File Size Before Optimization: 2,174,976 bytes
File Size After Optimization: 2,039,296 bytes
Gain: 135,680 bytes
Percentage in gain: 6%
In this project it has a much bigger gain; but again the gain in the file size is not important. But I did a test for memory usage and you were right. The optimized program uses less memory. Now, this I call gain I do not care about the HDD space but 100 KB of gain in the memory for each component is a quite good improvement. Sorry for being very harh before. Thanks for the code
Mustafa Demirhan
http://www.macroangel.com
Sonork ID 100.9935:zoltrix
<nobr>They say I'm lazy but it takes all my time
|
|
|
|
|
Mustafa Demirhan wrote:
One more thing: I think you also used MiniCRT. Right? If so, this picture is totally useless. Especially the compressed sizes will be nearly the same...
Nope. Standard MFC42.dll MSVCRT.dll etc. The compressed sizes does not include the same 3rd party dlls, only the ones that are generated by the project and the build tools. MiniCRT is only of value if you are totally forgoing the *entire* Microsoft libaries, and this includes MFC, ATL, MSVCRT, etc, not to mention global objects. I wouldn't consider using MiniCRT or any similar libary (there are dozens) for anything bigger than a single console app.
Visual Studio Favorites - improve your development!
GUIgui - skin your apps without XP
|
|
|
|
|
From the article:
<small<b>Why Not
The argument can be made that doing this is a waste of time, since the "zero bytes" will be compressed out in a zip file or install archive. Not really - it doesn't matter if the data is a string of zeroes or ones or 85858585 - it will still take room (20 bytes in a zip file, 29 bytes if only *4* of them 4k bytes are not the same) and time to compress that data and decompress it. Also, 20k of zeros is NOT 20k on disk - it's the size of the cluster slop- for Fat32 systems, 20k can be 32k, NTFS could make it 24k if you're just 1 byte over (round up). Most end users do not have the dual P4 Xeon systems with two gigs of RDram and a Raid 0+1 of Western Digital 120meg Special Editions that all worthy developers have (all six of us), so they will need any space and LOADING TIME savings they will need; taking an extra 32k or more out of your end user's 64megs of ram on Windows 98 is Not a Good Thing.
Just a lie. Totally ridiculous/wrong. Just trying to confuse people!
Mustafa Demirhan
http://www.macroangel.com
Sonork ID 100.9935:zoltrix
<nobr>They say I'm lazy but it takes all my time
|
|
|
|
|
Mustafa Demirhan wrote:
Just a lie. Totally ridiculous/wrong. Just trying to confuse people!
I must agree - your explanation makes so much more sense than the authors. Oh, wait a minute.....
In other words, what the hell is your problem ? It's unlikely the author set out to lie/confuse, so if you know better, then everyone, the author included, would be interested to hear why. Without that explanation, all you're doing is blowing hot air...
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
During last 10 years, with invention of VB and similar programming environments, every ill-educated moron became able to develop software. - Alex E. - 12-Sept-2002
|
|
|
|
|
It is all explained in the thread below!
Mustafa Demirhan
http://www.macroangel.com
Sonork ID 100.9935:zoltrix
<nobr>They say I'm lazy but it takes all my time
|
|
|
|
|
By the way, I agree that I was rude. I really did not mean that. I just wanted to point out that these are wrong, but I was way too rude. I am rwally sorry for that. I apologize for being rude.
Mustafa Demirhan
http://www.macroangel.com
Sonork ID 100.9935:zoltrix
<nobr>They say I'm lazy but it takes all my time
|
|
|
|
|
You wasn't rude at all, you was just "Aggressive" (that's the title of the thread)
Kochise
|
|
|
|
|
Well if I was unclear, let me know. But since a picture is worth a thousand words, I'll be posting a lovely little chart here...
Visual Studio Favorites - improve your development!
GUIgui - skin your apps without XP
|
|
|
|
|
I agree with Mustafa Demirhan ! It's the same for pocket digital camera ! Why should we save our pictures in packet JPEG when you can save them in plain unpacked TIFF on a 128 MB cartidge or IBM MicroDisc ? On PC, you will have soon gigabytes of memory, and terabytes of harddrives. Nobody would mind have an EXE of 145 MB just to display "Hello World !" on your screen. Nobody yet minds to have MicroSoft scerwing 140 MB of your main memory just after the boot, and 2 GB on your harddrive just to seat some useless assistants and drivers (drivers.cab - 75 MB - is loaded into the memory for immediate recognization of hot-pluged USB devices), when you have already these drivers supplied with your hardware. For whose cannot install them by hand, every one has to suffer from EXE/DATA size explosion.
I remember that good old time when I coded in full assembly language a little video player that support resume, pause, forward, backward, zoom, supersampling, RGB and CYM filter, ... ONLY 4 KB !
Kochise
|
|
|
|
|