It's a 10%-20% startup perf boost. The updater should set the compression flag on 10.6

You can't just -add- a compression flag, you need to actually compress the binaries.

Can't the files that are installed / updated / diff'd for the update mar be compressed prior to any of these operations? If so, then this is a build bug.

From reading the Ars article, the compressed data is stored in the resource fork, with an attribute indicating that it's compressed. Apparently writing the file explicitly will cause it to become uncompressed.

Just retested(using https://github.com/jrk/afsctool) on 10.6 with a harddrive there is a startup win of atleast 10%. In addition to being faster, this results in more stable startup numbers(ie less relying on non-deterministic seek penalty and more on cpu time to decompress). I think this is the last remaining huge startup win on OSX.

For the 10% win I did afsctool -c 9 99999999999 XUL To test, I rebooted the mac, waited for things to settle and then started firefox to about:startup(https://addons.mozilla.org/en-US/firefox/addon/about-startup/). I repeated this 3 times for the compressed/uncompressed case. I used the firstPaint column in about:startup as a measure of startup, but sessionRestored shows similar improvements.

Note one can get a few more percent of speedup by shipping the jar uncompressed and compressing it with HFS+.

How, exactly, do you do the compression?

> How, exactly, do you do the compression? Using afsctool, I assume. But where can one find afsctool?

> But where can one find afsctool? https://github.com/jrk/afsctool Sorry.

> Note one can get a few more percent of speedup by shipping the jar > uncompressed and compressing it with HFS+. ?

In comment 5, no need to reboot, just use "purge" in terminal between startups of the browser. As for compressed jars, perhaps Apple is using hardware acceleration found in Core 2, i5/i7 processors for decompression, and Mozilla is using software for decompression?

(In reply to Simon Howes from comment #11) > In comment 5, no need to reboot, just use "purge" in terminal between > startups of the browser. In theory yes, in practice no. OSX is stupid and has 2 separate caches: one for read()/write() IO and one for mmap() demand-paging IO. purge only flushes read/write. The only robust way to flush library code out of cache without rebooting is to put them on a separate partition and do umount/mount of it inbetween runs. > > As for compressed jars, perhaps Apple is using hardware acceleration found > in Core 2, i5/i7 processors for decompression, and Mozilla is using software > for decompression? No, the optimization here is simple. We are trading off reduced io for increased cpu usage.

Do we use compression under Linux and Windows?

No