Executable and DLL packing performance and footprint discussion & results
Oleg Rekutin
Compressor used UPX v1.04 (free GPL software).
http://wildsau.idv.uni-linz.ac.at/mfx/upx.html The browser seemed to be
fully operational after compression, including PSM.
All startup times are third startup in a row or later. All start up
times are measured with a hand timer, from click to time of appearance
of the main window.
Test system: AMD K6-2 450MHz, Windows 98 SE, 128MB RAM and I forget the
speed of my hard drive.
First batch of results:
Original installation size: 14,782K (dll & exe: 10,656K)
Original installation start up time: 23 seconds
*.exe compressed only size: 14,078K (dll & exe: 9,951K) savings: 704K
*.exe compressed only start up time: 23 seconds
*.exe *.dll compressed size: 8,537K (dll & exe: 4,410K) savings: 6246K
*.exe *.dll compressed start up time: 24 seconds (barely)
During startup, I see hard drive working for 2 to 4 seconds or so, and
until 20th or 21st second, Mozilla just sits there, using 100% CPU
(loading, I assume, but I don't know what exactly it's doing). This is
true for all start up times above and explains the almost-constant start
up times: the hard drive activity takes only around 3 seconds.
To measure impact on loading time, I decided to measure first start up
time immediatelly after rebooting the computer.
Original installation fresh start up time: 33 seconds (approximately
15 seconds of HDD activity)
*.exe *.dll compressed fresh start up time: 29 seconds (approximately
12 seconds of HDD activity)
So the 6 megabyte savings in footprint actually speed up the start up
time because less data must be read from the hard drive. I expect start
up speed gains to increase with a faster CPU and/or a slower HDD. If the
CPU is slow, but HDD is fast, then start up speed gain will decrease.
For example, I expect compressed exe and DLL Mozilla to start
significantly faster from a parallel-port ZIP disk, while I expect
compressed exe and DLL Mozilla to start slower on a 100Mhz Pentium
system off a high-performance SCSI drive or a RAM disk.
I don't know how to precisely measure footprint impact of the
compressor. Rough measurements, using TaskInfo 2000 "InMem KB" are as
follows (averaged over three runs):
Original installation in mem KB: 20,652KB
*.exe *.dll compressed in mem KB: 22,860KB (loss: 2,208KB, 10.7% gain)
Browser was simply opened with google.com as its home page. As I watch
"In Mem KB" change during Mozilla's startup, I see that the compressed
Mozilla jumps to about 15MB InMem 6 seconds after startup. Uncompressed
Mozilla, however, jumps to about 9MB InMem 6 seconds after startup. This
seems to indicate that the memory footprint increase is a direct result
of executable compression overhead at start up. The implication is that
after a long web surfing session, the difference in memory footprint
between compressed and uncompressed Mozillas should be about the same.
To test this, I opened each version and visited 13 sites (Disney seemed
to be down at the time of testing) listed under Debug/Verification menu
in the listed order, giving each page enough time to load completely
(sometimes almost completely). At the end, I opened Mail/News. Cache was
cleared before the two runs.
Original installation in mem KB after surfing: 27,864KB
*.exe *.dll compressed in mem KB after surfing: 30,552KB (loss:
2,688KB, 9.6% gain)
In my opinion, this confirms that the memory footprint cost is only
incurred at startup and does not affect the rest of the surfing.
A little bit more detail:
*.exe compression:
File size Ratio Format Name
-------------------- ------ ----------- -----------
342240 -> 54784 16.01% win32/pe mozilla.exe
724992 -> 314880 43.43% win32/pe psm.exe
5488 -> 3584 65.31% win32/pe regxpcom.exe
37216 -> 16384 44.02% win32/pe ren8dot3.exe
-------------------- ------ ----------- -----------
1109936 -> 389632 35.10% [ 4 files ]
*.exe *.dll compression:
Unfortunately, I couldn't capture UPX output in this case. One of the
DLLs remained uncompressed however (reported Not Compressible by UPX).
Compressed total DLL size was 4,126,272, while original was 9,800,440,
which yields the approximate average compression ratio of 42%.
Note: UPX is a cross-platform compressor. I'd love to see somebody do
the same sort of testing on a Linux system. UPX does not support
Macintosh systems or various Unix systems.
Conclusion:
Compressing all DLL and EXE files saves 6 megabytes on the hard drive
and cuts the start up time on most systems. Extra memory footprint cost
incurred is approximately 2-2.5MB (which is approximately 10% extra of
initial start up memory footprint) and barely grows as the browser is
used. Start up time and hard drive footprint savings outweigh the memory
costs for the majority of users.
Recommendation:
Since UPX is GPLed, we should compress all DLLs and EXEs of Win32
installer nightly builds and milestone releases. (Non-installer builds
have too much fat, the extra debug .EXEs, the uncompressed chrome, etc.)
Commercial and non-commercial distributions of Mozilla, such as Netscape
6.x or Beonex should also ship their releases with DLLs and EXEs compressed.
Disclaimer: Everything is, of course, in my opinion and I could be
wrong/blind, etc. Feedback welcome :)
(P.S. Should a bug be filed on this?)
(P.P.S. Posted with the compressed version of the abovementioned build.)
Henrik Gemal
please do file a bug, and please cc me on it (ge...@gemal.dk)
Oleg Rekutin wrote:
--
Henrik Gemal, ge...@dk.net
Webmail Evangelist
TDC Internet
Sebastian Späth
> > Compressor used UPX v1.04 (free GPL software).
> > http://wildsau.idv.uni-linz.ac.at/mfx/upx.html The browser seemed to be
> > fully operational after compression, including PSM.
> > Recommendation:
> >
> > Since UPX is GPLed, we should compress all DLLs and EXEs of Win32
> > installer nightly builds and milestone releases.
I did post a similar test earlier and while the result are impressing, I
got to know a couple of disadvantages:
- The deinstaller will be loaded into RAM as well, resulting in a
300-400kb bigger RAM usage per file as you noticed.
- Resulting in the changed loading structure it is not possible to reuse
.dll's for different applications, instead they will be reloaded every
time. (Don't ask me for reasons, I'm no code guru) You should try to
verify or disverify this by loading two or three instances of Mozilla
and see how different the RAM usage is in that case.
- Hard disk space is cheaper (in $/MB) than RAM usage
- This method doesn't work with self modifiying dll's (which mozilla
doesn't have).
Sebastian
Randell Jesup
>During startup, I see hard drive working for 2 to 4 seconds or so, and
>until 20th or 21st second, Mozilla just sits there, using 100% CPU
>(loading, I assume, but I don't know what exactly it's doing). This is true
>for all start up times above and explains the almost-constant start up
>times: the hard drive activity takes only around 3 seconds.
This says to me that our big problem is NOT DLL's, our big problem
is way too much startup processing. Does anyone have a good profile of
startup for an average setup?
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rje...@wgate.com
John Bandhauer
footprint is a *much* bigger priority than reducing disk footprint.
This scheme *costs* memory that we can't afford. It also will have
an unknown effect on the normal physical page swapping scheme
generally used for code. On Win32 at least, unmodified memory pages
from exe and dll files can be swapped out without any work because
the system knows that swapping them back in just means re-reading
from the original file.
I admit that I have not dug into upx deep enough to figure out exactly how it works, but...
Depending on how this compression system works, it is likely that
the pages it swaps out would be seen by the system the same as
allocated memory and would need to take up space in the general
swap file. That would not be good.
From the docs (upx.pod):
"Because of the way UPX (and other packers for this format) works, you
can see increased memory usage of your compressed files. If you start
several instances of huge compressed programs you're wasting memory
because the common segements of the program won't get shared
across the instances.
On the other hand if you're compressing only smaller programs, or
running only one instance of larger programs, then this penalty is
smaller, but it's still there."
And, as far as Win32 goes, users can get the same sort of compression
benefits by using the lower-level compression built into the OS. I
just don't see incorporating this technology as a general win for
mozilla. Vendors who see it otherwise are, of course, free to apply it
to their distributions.
John.
John Bandhauer
footprint is a *much* bigger priority than reducing disk footprint.
This scheme *costs* memory that we can't afford. It also will have
an unknown effect on the normal physical page swapping scheme
generally used for code. On Win32 at least, unmodified memory pages
from exe and dll files can be swapped out without any work because
the system knows that swapping them back in just means re-reading
from the original file.
I admit that I have not dug into upx deep enough to figure out exactly
how it works, but... Depending on how this compression system works,
it is likely that the pages it swaps out would be seen by the system
the same as allocated memory and would need to take up space in the
general swap file. That would not be good.
From the docs (upx.pod) describing Win32 issues:
"Because of the way UPX (and other packers for this format) works, you
can see increased memory usage of your compressed files. If you start
several instances of huge compressed programs you're wasting memory
because the common segements of the program won't get shared
across the instances.
On the other hand if you're compressing only smaller programs, or
running only one instance of larger programs, then this penalty is
smaller, but it's still there."
And, as far as Win32 goes, users can get the same sort of compression
benefits by using the lower-level file system compression built into
the OS. I just don't see incorporating this technology as a general win
for mozilla. Vendors who see it otherwise are, of course, free to apply
it to their distributions.
John.
Randell Jesup
>I disagree with your recommendation. I think that reducing memory
>footprint is a *much* bigger priority than reducing disk footprint.
>This scheme *costs* memory that we can't afford. It also will have
>an unknown effect on the normal physical page swapping scheme
>generally used for code.
I agree ABSOLUTELY. Reducing disk footprint is nice, but not
exactly critical, except where it also reduces startup time (like less
files to open and read, etc). And even there there are tradeoffs to be
done.
John Bandhauer
like a very slick package. And I do appreciate the work Oleg put
into the analysis. I just don't think it is a good match in
general for the set of problems we have with mozilla.
John.
Oleg Rekutin
obviously did not consider all issues. I had no idea about the page
swapping issue.
It would benefit the work to run more tests, but I no longer have the
time or the interest, given the arguments that memory footprint is more
important that disk footprint and that disk storage is very cheap these
days. Also, considering the cost of inability to share common segments
of multiple instances of the same code, I now think that the benefits of
executable and DLL packing probably do not outweigh (if they do at all)
the costs to a reasonably significant extent. In other words, whatever
the benefits are, they do not seem to be worth the effort.
However, I jumped to a conclusion in my original post, and I don't want
to jump to a conclusion again. One would have to run a batch of tests
measuring memory footprint impact of running multiple instances of
Mozilla (not just multiple windows open) and evaluate the likelyhood of
such cases occuring to lend more credibility to the findings'
conclusion.
Thanks for pointing these issues out to me. :)
- Oleg