Closed Bug 311530 Opened 19 years ago Closed 9 years ago

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

Categories

(Firefox :: Shell Integration, defect)

1.5.0.x Branch
PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: bryan, Unassigned)

References

()

Details

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.
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.
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.
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.
> (as mentioned in comment #22 above and bug 311538) Oops, I should have said "bug 311530".
Oops again :-) Please ignore comment #4 (and this comment) -- it was meant for a different bug.
Version: unspecified → 1.5.0.x Branch
afaict, None of the cited URLs work - tests are gone
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.