Closed Bug 79580 Opened 19 years ago Closed 19 years ago

Reorder jar files to improve startup performance


(SeaMonkey :: General, defect)

Windows NT
Not set


(Not tracked)



(Reporter: rogc, Assigned: rogc)




(3 files)

In a hallway conversation today, I agreed to prototype a tool
which would reorder the contents of .jar files so that contents
are stored in the same order in which we read them at startup.

Blocks: 7251
Will it produce a noticeable performance improvement ?

I suspect this change will be very difficult to maintain in future releases.
We will need to keep a list of files sorted in the "proper" order, updated to
reflect code changes and jar changes.

Does it worth the trouble ?
As with all performance optimizations you have to do the work and then 
measure to see if your guess at what would help really did.
Would it make sense to have some API where all the contents of a jar are just
dumped into the cache without using all the streams etc?  (Seems like that could
be a big win for some jars.  Pav has also been interested in getting directly at
gif files without all the overhead of using our streams...)
I think it makes sense to bypass nsIOService when we *know* we're
reading from the local disk.  Once that has been accomplished, I'm
not sure that preloading the image cache with images needed for
start-up will help performance... but it's certainly worth trying!
I have prototyped a .jar file reorderer, and run a bunch of
start-up timings.

Result: a very small improvement in cold start and no improvement at
all for warm start (The numbers actually show warm start getting
worse, but by such a small amount that it's in the noise).

These results are not surprising, although I was hoping for more
improvement in the cold start case.

I ran this on a 650MHz PIII, 512MB, NT 4.0.

Here are my timings:

    cold start reorder:
    avg: 15.703
    cold start original:
    avg: 16.056
    net diff: .356 (2.2% better)
    warm start reorder:
    avg: 3.530
    warm start original:
    avg: 3.525
    net diff: .05 (1.4% worse)

I'm going to attach some stuff to this bug so other people can try on
other platforms to see if it makes more difference.  Please contact me
if you need help!

OK, here are some suggestions for using this stuff (assuming you're
running bash from cygwin; sorry, I'm a Unix guy :-):

Save and in c:\temp

    cd $MOZ_SRC/dist/WIN32_O.OBJ/bin
    mv chrome chrome.orig
    cp -r chrome.orig chrome
    cd chrome
    unzip c:/temp/
    for package in US chatzilla comm en-US en-win help messenger modern toolkit
	perl c:/temp/ $package.jar $package.order

Now try measuring start-up time with the new chrome directory, and
comparing with start-up time with the old chrome directory.

(There's no need to apply the patch in the bug; that's just for
generating the .order files)


forgot to update my results to this bug:

machine used: win98 200mHz, 128Mb RAM
I ran the test last Friday, 5/18, and used a commercial build from that day.  
Here is the average of 3 runs from a watch clock.

       original JARs      with JAR ordering
cold      27.34                 27.66
warm      10.33                 10.66

There isn't much difference I saw, but again I tried this on commercial build, 
and not all the JAR files got reordered.   

I guess I need to try apply the re-order tool to all JARs to see if that helps.  
Roger, will your re-order tool work with other JARs that's not listed in your 
comment above?

I generated those .order files using a commercial build, so
any .jar files that did not have corresponding .order files
represent .jar files that were not accessed during startup
under my instrumentation.

So re-ordering .jar files does not improve startup time.
Surprising, but good to know.
Given the data from our experiments, reordering the .jar files
does not help very much.
Closed: 19 years ago
Resolution: --- → WONTFIX
No longer blocks: 7251
Blocks: 7251
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.