Apprunner/viewer is very slow at resizing (and MAINLY if someone tries to the drag-thing to get more space for the bookmarks/alerts-panel) (And my machine is NOT a slow thing; and the problem still occurs on a Ultra5 with 333MHz/2MB-L2-Cache/512 MB). The machine uses a 8 bit display, maybe here lies the problem... Tested with nightly build 1999-05-12-08 on a Solaris 7 Generic_106541-03 sun4u sparc Ultra 5 - 270 MHz

Chris, another general performance problem ...

lets try ramiro first to see if he has something up his sleve on linux...

*** Bug 7396 has been marked as a duplicate of this bug. ***

*** Bug 7396 has been marked as a duplicate of this bug. ***

A big piece of the performance problems seems to caused by extensive disk access. Try to start ./apprunner from a NFS-driven home-directory (10baseT) and watch the network LED... This problem can be reduced by doing things like "component registration" and other file-access-extensive things on parallel, filling gaps where no file-accesses are made. ---- Another idea is the JAVA-*.jar idea: Pack all related files in ONE *.jar-archive (and please use the *.jar format, DO NOT invent the wheel again !!!!!) and load it once at startup.

marking m10. Im working on performance bugs/problems, but in rendering. Disk access is another story and an xpcom/ component manger thing. Reassigning to dp@netscape.com If would be interesting to compare the nfs performance with a local disk installtion on the same build and platform.

local harddisk performance seems to be little bit better. Using /tmp on a Solaris 7 box with 512MB __rocks__ (e.g. build and run from it =:-) ). Dumb question: How to measure disk performace vs. nfs disk performance vs. /tmp disk performace (tmp is at least a memory-to-memory copy...) ?

Prepoulating registry removed most of the disk access.

Looking good. Marking Verified...I think this is the best we'll get.