site  contact  subhomenews

Faster SeaMonkey

June 15, 2013 — BarryK
There is a long story here. I have been watching a gradual degradation in the performance of SeaMonkey over the years.

There is a configure option for the source code, "--enable-chrome-format=", which can have parameters "flat", "jar", or "omni".

I don't recall which version "omni" was offered, but prior to that it was just "flat" and "jar".

This has all the files in the 'chrome' folder as individual files, not in a zip archive.

The files in the 'chrome' folder are grouped into 5 or 6 zip archives.

The entire chrome folder, plus some other stuff, is a single huge zip archive.

My experiments a few years ago showed that flat is faster in a squashfs archive, compared to jar, I think basically because having zip files inside a squashfs file means two levels of decompression required to read the contents.

More recently, I think it was the Firefox developers who decided that a single big zip file was faster, and omni made its entrance. If you look inside /usr/lib/seamonkey, you will see 'omni.ja', a 9MB monster.

However, I became convinced that omni actually made SM slower!

Unfortunately, when the developers lost interest in 'flat', it became broken. Then when they lost interest in 'jar', it also became broken -- SM compiles, but "make install" is broken.
So, I resigned myself to omni.

Then today I decided to try something. I expanded 'omni.ja' -- by first renaming it to, then right-click and choose 'pupzip', then I expanded it into a directory that I named 'omnidir'.

I then created a zip file without any compression, like this:

# cd omnidir
# zip -0 -y -R ../newomni '*'

The '-0' is a zero, and means no compression.

It created '' that I renamed as 'omni.ja'

My reasoning is that SM will run faster when we build it in with Woof, as omni.ja will be in a squashfs file and only one level of decompression will be required.

The new omni.ja is 28MB, compared with the original at about 9MB. What this tells me is they have used a very high level of compression.

Anyway, now for the surprise. I am currently running Raring pup in a full-HD installation, and I replaced the omni.ja with my new one, started SM, and... everything seems faster! Is this my imagination?
SM with the big 28MB omni file seems faster than with the original.

I am unimpressed with some of the decisions made by the Firefox developers (most of which ends up in SM). I am still not happy with the single omni.ja file, but I have now done something to improve performance.

The icing on the cake is that the live-CD iso file will be about 1MB smaller -- as squashfs is not very good at compressing an already-compressed file.

The next build of Precise Puppy (and maybe I will release a build of Raring Puppy), will have this improvement to SM.

PET for Precise and Raring (26.1MB):


internet security helper
Username: scottman
This may be of no interest to you: To be vain and quote myself: [i]"with the constant encroachment of CISPA, PIPA, SOPA and whatever the next acronym will be, I thought something like `netsecurity` should pop up on screen as soon as a net connection is detected for the first time - it could be called from [b]delayedrun[/b], before the flash-installer, for example. I will be doing this in Akita. Puppy should lead the way in all distros in protecting users online security, and even privacy - I think someone on this forum could come up with something similar, but much better than this one."[/i]

re security helper
Username: BarryK
"scottman, That's a nice idea! I have added it to my to-do list to try it out.

Re uncompressed squashfs
Username: BarryK
"Ted Dog, Yes, I was toying with the idea of offering to convert the zx'ed squashfs file to gz'ed, as the latter gives noticeably faster startup times on older hardware. For example, if you boot from the live-CD, then at first shutdown when it asks if you want to copy the squashfs file(s) off the CD to HD, it could also offer to convert from xz to gz.

Tags: puppy