Unique way to make Firefox load faster

[nosh]

This one's apparently been out there for long but I couldn't easily find a reference to it on DC.

The tip basically asks us to use upx to compress *.exe and *.dll in the main Firefox (installation) folder and *.dll in the "components" and "plugins" subfolders.   
I haven't timed it but I'm pretty certain Firefox actually does load faster after I upx'd the files.

If any of you go for it please note down your FF load time before compression so you can observe the difference and post your results here.

Link

[masu]

I agree
I also use this technique to improve the startup time for FF.
As long as you have enough memory, this tip should work 

[Ralf Maximus]

I don't doubt the performance claims (I'm off to try it for myself in a bit) but... this seems totally counterintuitive.  How can compressing an executable improve performance?  Wouldn't any gains made by loading smaller files be lost during the decompression process?

Or is it true that this technique only applies to certain classes of executable?  For instance, FireFox is a win, but running upx on (say) Microsoft Office makes things worse?

UPDATE: I tried it, and sure enough, FireFox seems zippier.  Purely subjective, but it really does seem to load faster.

I did some quick googling on UPX and learned that the effect works well for applications that are run once (e.g. FireFox) but does not work very well for applications that load multiple times and "share" memory footprints (Office, for example).  For those apps, the compressed nature of the .exe prevents Windows from sharing the memory, resulting in multiple copies of the same .exe eating up identical chunks of RAM.  May be a trivial matter on a 2GB workstation, or maybe not -- its your call to make.

Also, I learned that UPX uses an in-place decompression routine which means it (usually) does not generate temporary files.  This is good, in that reading the whole compressed .exe and writing out a decompressed version before running it would actually degrade performance, not enhance it.

Some performance gains may be due to the virus scanner you use.  Many cannot read a UPX-compressed executable beyond the loader, which short-circuits scanning of the whole file (which is seen as data).  Thus, instead of scanning (say) 10 megabytes of .exe for malware, only the first few K are scanned -- a significant savings.

The flip side to this is a bit worrisome: if your virus scanner cannot penetrate the .exe, it can't protect you.  Many viruses & trojans come compressed with UPX (or similar techniques) for this reason alone.

I checked and the scanner I use -- NOD32 -- does scan UPX compressed executables.

As in most things, the bottom line is: YMMV.  The FireFox hack seems to be a win, and so I'll keep it.  But thanks to nosh I learned about a new utility today which I will use to experiment with on my own projects.  Thanks!

[MrCrispy]

Compressed exe's run faster because on modern cpu's, uncompressing takes less time than disk IO. This is the same reason why realtime encrypted filesystems (like EFS or TrueCrypt) can sometimes do better on benchmarks as long as the encryption algorithm is simple enough.

But I really don't see much need for this. FF is one of those apps which I load once and it keeps running always. I wish the devs would fix the huge memory leaks in FF, its the only reason I ever restart FF (that and adding an AddOn).

[nosh]

And thank you for your post Ralf, coz I was wondering the same thing about compression vs efficiency and the downside (if any) to it all and you've shed some light on these matters.

MrCrispy, I'm with you on never shutting FF down, I've even customized it by removing the close button and replaced it with minimize so I don't close it by accident, one of the best decisions I've made, in retrospect. Even so, I do have to start FF atleast once a day and any time I can shave off its long (to put it mildly) loading time is a good thing. From what I hear FF3 is an even bigger memory hog, now _that's_ an achievement!

[Renegade]

I wish the devs would fix the huge memory leaks in FF, its the only reason I ever restart FF (that and adding an AddOn).

-MrCrispy (October 22, 2007, 11:20 PM)

This is one of the main reasons that I use Opera now.

The hack is interesting... I'll have to give that a look-see. Never would have guessed that...

[f0dder]

Remember that you need a reboot (or other way to flush the filesystem cache) before you do your timing.

Indeed compressing executables mean that their memory can't be shared. Pretty bad if you're running multiple instances of something, especially if it's in a terminal server environment.

UPX and other exepackers indeed don't decompress-to-disk, that would make them useless.

If you're using a virus-scanner that can't scan into UPX executables, get a different scanner, as the one you're using is useless. This also means that, if you're using a virus scanner that doesn't suck, UPX'ing executables can slow down startup time quite a bit.

When UPX'ing an executable speeds things up, it means the executable is horribly bloated and has a crazy loading pattern. The problem isn't really with disk speed as MrCrispy says, but that executables are "demand-loaded" in 64kb chunks... if windows did a one-blast read of the executable instead, things would be different.

EDIT: doesn't seem to speed up things here anyway, as slow as ever to boot up. The ff devs really ought to spend some time fixing bugs and leaks, and tracing ff startup to optimize it, instead of adding new features.

[BigJim]

But I really don't see much need for this. FF is one of those apps which I load once and it keeps running always. I wish the devs would fix the huge memory leaks in FF, its the only reason I ever restart FF (that and adding an AddOn).

-MrCrispy (October 22, 2007, 11:20 PM)

My practice is the same, MrCrispy. As such I find there's a very useful feature in the Update Notifier Add-On (in itself a real time saver!) labeled 'Restart Firefox ...". I'll often hit that when I leaving my desk for a few minutes and it's done the job by the time I return.

Neat on removing the close button, nosh. I'll bite. How did you do it?

[Ralf Maximus]

UPX and other exepackers indeed don't decompress-to-disk, that would make them useless.

According to the UPX website (http://upx.sourceforge.net/) this may not always be the case.  They are careful to say that under some circumstances the .exe cannot be decompressed in RAM, and must be uncompressed to a file then run from that.  Unfortunately they do not describe what those circumstances are.

Even a low memory condition should force unpacking into the paging file, right?  Mmmmm, the smell of performance.

Or perhaps this is a nod to their cross-platform crowd -- maybe running the Atari or DOS versions of UPX do this, but not the Windows version.  I'm satisfied that the Windows build seems to use RAM exclusively, at least on the few (half-assed, completely unscientific, probably drunk at the time) tests I've run here.

Observation: The UPX project appears to have started in 1996.  That means that when UPX got rolling computers were slow, had one-tenth the memory, and bandwidth was dragged through 56K modems like taffy.  Back then, compressing .exe files for download made a lot of sense. 

Unpacking the bastards probably took a loooooong time, but was considered worth it by some.  I can easily see some websites deciding to use UPX, because making people use PkUnZip was "too complicated".

The fact that UPXing a file can actually enhance performance is a happy side-effect, a complete accident of modern PC hardware.

[f0dder]

Ralf Maximus: one of the "has to be decompressed to disk" used to be the case with ELF compression, and iirc they had some lame excuse like "linux is a properly protected OS unlike windows" - but afaik these days, they learned how to do in-memory elf decompression.

Yes, a low-memory situation could force other applications to the paging file, and the decompressed-to-memory executable can of course be paged out as well (as opposed to discarded and re-read, as normal executables are handled).

Unpacking didn't take a long time back then either (compression is slow but decompression is very fast, that's one of the traits of the class of compression algorithms generally used by exe packers) - and disk drives were MUCH slower back then (who where remembers PIO modes?).

[nosh]

Neat on removing the close button, nosh. I'll bite. How did you do it?

-BigJim (October 23, 2007, 07:21 AM)

A combination of MenuX which adds buttons with additional functionality ("incompatible" since the last several (2.x) versions of FF) & Menu Editor (lets you hide conventional menus) if memory serves correctly, coz I did this way back and haven't touched these extensions since. The screenie depicts the top of my display with FF active - the title bar and menus are hidden, not cropped out of the image.

 Unique way to make Firefox load faster

[mrainey]

After doing the upx thing, Firefox crashed every time I tried to download from one of my longtime favorites, Megaupload.com.  Reverting to uncompressed Firefox stopped the crashing.

Didn't seem faster anyway.

[nontroppo]

Note, Opera is compressed by default. I actually do the reverse - I like to uncompress the DLL because I use multiple profiles run simultaneously and compresed DLLs cannot be shared. There is also a slightly higher memory footprint on first start as the whole DLL must be loaded, as opposed to just the parts that are needed.

If you use Process Monitor, I remembered most of the FF startup is not reading executables, but XUL associated files (it was ages ago that I profiled though). Opera spends most of its time validating cache entries, thus these techniques have no impact on the majority of the the startup I/O I believe...

[Grorgy]

You can also use Minimize to Tray extension to stop firefox closing, its one of the options.