Closed Bug 534246 Opened 15 years ago Closed 6 years ago

Enable HFS+ compression on application files during update

Categories

(Toolkit :: Application Update, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: taras.mozilla, Assigned: joelr)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [ts])

It's a 10%-20% startup perf boost. The updater should set the compression flag on 10.6
Whiteboard: [ts]
Summary: Enable HFS+ compression on application files → Enable HFS+ compression on application files during update
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.
Assignee: nobody → joelr
Blocks: 447581
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?
OS: Linux → Mac OS X
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.