311530 - Many small applets on a page causes page to load extremely slowly

Status: RESOLVED INCOMPLETE

(Firefox :: Shell Integration, defect)

Description

[Bryan Keller]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412.7 (KHTML, like Gecko) Safari/412.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

When a page has many small applets on it, Firefox takes extremely long to load the page. In the given 
example, the page on my hardware can take up to 30 seconds to load. Now Java is no speed demon, 
but the page loads in under 5 seconds in Safari so I think there is room for improvement here. It almost 
seems as if a separate Java VM is fired up for each little applet. Massive memory usage is also a 
problem. The browser becomes unresponsive during the wait, so it appeared at first as if the browser 
had hung.

My hardware:
Powerbook G4 1.67, 1 GB RAM, OS X 10.4.2


Reproducible: Always

Steps to Reproduce:
1. Load the URL http://java.sun.com/applets/other/Bullets/huebullet.html
2. Wait for a while


Actual Results:  
The page comes up, but after a long wait. At first I thought the browser had hung.

Expected Results:  
The page should come up faster and hopefully with less memory usage.

Comment 1

[Bryan Keller]

I just tested this page in Firefox 1.0.7, and the page loads about as fast as Safari, less than 5 seconds. So 
it appears to be something introduced in 1.5 beta.

I noticed that in the 1.5 beta, when I looked at the "about:plugins" page, I see a "MRJ plugin", which is not 
present in 1.0.7. So I looked in the 1.5 app bundle, and low and behold there is the Java plugin. I am 
betting this is causing the performance problems. It was probably added to support JDK 1.4 and above. I 
have played around with this plugin (http://javaplugin.sourceforge.net/) but I don't think it is ready for 
prime time.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Yes, this page takes a long time to load using Firefox 1.5 Beta 2, which
bundles the Java Embedding Plugin -- about 30 seconds (in my tests) on Mac OS
X 10.4.2, and about 20 seconds on OS X 10.3.9 (I have a dual-1Ghz-CPU PowerPC
G4).  Safari takes about 5 seconds to load this page fully (on both OS X
versions).

But loading this page causes about the same increase in RAM usage with Firefox
as it does with Safari.  Using 'top' (on OS X 10.4.2), I saw an increase from
153 MB to 394 MB in Safari's RAM usage, and from 168 MB to 425 MB in Firefox's
usage.

As for the appearance of being hung, that's an artifact of how all of
Mozilla.org's browsers load applets -- which doesn't get along well with how
applets actually need to be loaded in Apple's JVMs (for Java 1.4.X and
higher).  Mozilla.org browsers load applets synchronously:  They assume that
an applet will be up and running by the time the call to load it has returned.
But, in Apple's JVM, applets (and the JVM itself) load asynchronously -- it
can be one or two seconds between the time the browser starts to load an
applet and the time it finishes loading, and for most of that time it isn't
yet ready to receive commands from the browser.

You might think this shouldn't matter.  But Mozilla.org browsers sometimes try
to do things with an applet immediately after it's loaded (or appears to have
been loaded).  An example is LiveConnect calls from JavaScript onload handers,
which are often used by online banking sites.  These won't work if the JEP
lets the browser have its way.

So the Java Embedding Plugin waits for each applet to get to a certain stage
in its loading before returning control to the browser's UI.  During this wait
the browser can appear to be hung.  And since Mozilla.org browsers seem to
load applets on the same page sequentially, the waits get added together, and
can become significant for pages that contain lots of applets.

Safari, I believe, gets around this problem by loading each applet in a
separate thread (and waiting for a callback to tell it that an applet is
"ready").  The Java Embedding Plugin also loads each applet in a separate
thread.  But the JEP only starts loading an applet after the browser has
requested it (which happens sequentially), and each of these threads needs to
wait a second or two for its applet to be "ready" for the browser to start
sending it commands.

So, in sum, I'm probably not going to be able to do anything about the
appearance of being hung while loading a page that contains lots of applets.
But I may be able to reduce the delay (the fact that it's longer on OS X
10.4.2 seems to indicate that there's some leeway for me to do this).

(There's a related discussion at bug 309122.)

Finally, I should note that very few pages contain as many applets as the URL
you cited.  I've done a lot of testing on pages with multiple applets, and
most of them do reasonably well.  Here are some examples:

There are a bunch of test pages here containing multiple applets:

http://www.mozilla.org/quality/browser/front-end/testcases/oji/tagstest.html

And here's my favorite JEP torture test:

http://brittnysseafood.com/

> I have played around with this plugin (http://javaplugin.sourceforge.net/)
> but I don't think it is ready for prime time.

When you find specific problems, you should file bug reports.  Then I might be
able to fix them.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

If you use the -Djep.asyncinit=true setting described at
https://bugzilla.mozilla.org/show_bug.cgi?id=309122#c6, Firefox 1.5 Beta 2
loads this page in about 5 seconds (the same as Safari) on both OS X 10.4.2
and 10.3.9.

But I _don't_ recommend using this setting.  It breaks a bunch of things,
including JavaScript onload handlers that call applet functions via
LiveConnect.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

> (as mentioned in comment #22 above and bug 311538)

Oops, I should have said "bug 311530".

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Oops again :-)

Please ignore comment #4 (and this comment) -- it was meant for a different
bug.

Comment 6

[Wayne Mery (:wsmwk)]

afaict, None of the cited URLs work - tests are gone