187264 - freezing user interface + fix (fastload issue)

Status: VERIFIED DUPLICATE of bug 169777

(Core :: XUL, defect)

Description

[erik.nolf]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203
Build Identifier: ftp://ftp.belnet.be/mirrors/ftp.mozilla.org/pub/mozilla/releases/mozilla1.2.1

The more components (dialogs, windows) we tried to open, the longer it took
to appear. This line in user.js fixed our freezing user interface:

user_pref("nglayout.debug.disable_xul_fastload", true);


Reproducible: Always

Steps to Reproduce:
1. just open some dialogs (for example preferences and sub entries)
2.
3.

Actual Results:  
The interface got sluggish: 100% CPU usage + "Not Responding"


Expected Results:  
A faster displaying of such widgets

Hi,


The issue above almost killed our migration to Mozilla and this would have
been a real shame since "user.js" is just soooo powerful from a modest sysadm
point of view. The line that saved our project:

        user_pref("nglayout.debug.disable_xul_fastload", true);

We like to mention it here because it was really hard to find and yet so simple.
Googling shows a lot about performance issues but not in particular to a
freezing userinterface and a rather default install. After all, we're just
a regular user, nothing more. So here goes the background of our setup and
findings.

A normal WinNT4.0 + SP6a domain with roaming profiles of 10 clients at most
and a fast switched ethernet; so nothing to worry about. After all, we had
Mozilla tested quite successfully on our home PC (win2K + linux). Now it was
time to use it for our small workgroup.

We did a *default* Mozilla 1.2.1 install (+ extras: calendar, flash, java).
Then we migrated "Netscape Communicator" profiles manually, not to the default
"Application Data" (bad for roaming profiles) but on a separate shared M:\
disk. Each user got his/her new "registry.dat" and an approriate "user.js"
file in order to set caching on the clients local C:\ drive. No reboot needed;)

Everything seemed fine. Browsing was quite fast but then it showed: the more
components, windows or dialogs you opened the slower it went: with 100% CPU
usages and "Not Responding" stuff in the task manager. For example opening
preferences could take a long time, not to mention selecting some entries.

Once a dialog was displayed it opened faster but new dialogs took longer
and longer to appear.

The share disk was quickly browsable and disabling antivirus stuff didn't
work. We did saw an unknown XUL.mft file growing in our mozilla profile.
Removing it suddenly improved opening new dialogs until it reached a certain
size ...

Looking for more info on this file and how to disable it brought is to:

        user_pref("nglayout.debug.disable_xul_fastload", true);


We feel glad now. The comming days Mozilla will be tested in our production
environment.


We hereby wish you all a happy new *Mozilla* year,


        Erik

Comment 1

[timeless]

.

Comment 2

[R.K.Aa.]

the XUL.mfl related hang when opening prefs is bug 169777
A few other freezes are dependencies in bug 134576

Comment 3

[Boris Zbarsky [:bzbarsky]]

ccing ben and brendan...

Comment 4

[Ben Tremblay]

The old lizard took an impossible number of shots to drive off my desktop, and 
then I found a stub in Taskbar with "Exit Mozilla" grayed out.

timeless: putting talkback zip in didn't help since the report was never 
itiated, i.e. "freeze" not "crash"; the patch to put in the menu item is the 
way to go.

Comment 5

[Boris Zbarsky [:bzbarsky]]

This is almost certainly a dup of bug 169777 (especially if it no longer happens
with recent nightlies)

Comment 6

[Serge Gautherie (:sgautherie)]

Reply to comment 5:

I read parts only of the description;
but it sure looks like a dupe of bug 169777 comment 126 !

May be you can cut & paste "user_pref("nglayout.debug.disable_xul_fastload",
true);" into a new comment of bug 169777 to be explicit there.

NB: bug 169777 already covers build from v1.2a to v1.3a, including v1.2.1.

PS: jrgm warned(!) not to use 'disable_xul_cache'; I don't know what his current
position is on 'disable_xul_fastload' for buggy (= before his patches) builds.?.

Comment 7

[John Morrison]

Actually, I think Erik's point is that his user profiles were located on a 
network share, in which case the slower I/O negates the advantage of serialized 
fastload file. There is a bug that suggests relocating XUL.mfl to the disk 
Cache folder so that when users set the disk cache to a local drive, the 
XUL.mfl comes along for the ride. Alternatively we could formalize some 
solution that disables fastload in these remote drive cases, although I 
prefer the 'Cache' solution since it is a little easier for users to deal 
with that single concept, as opposed to dealing with a separate pref.

Comment 8

[Serge Gautherie (:sgautherie)]

Reply to comment 7 (and 6 :-<):

Eventually I read the whole description, and fully agree with you ;-<

Now:
*Shouldn't bug 134576 be on the "blocks" line rather than the "depends on" ? ;->
*This bug could even be marked as a duplicate of bug 130041 ! (Or at least one
could depend on the other...)

Comment 9

[John Morrison]

Actually, I read this again, and now I'm not sure what the point was. 
The "not responding" stuff is definitely bug 169777. But the other stuff
about "opening more dialogs" and "remote share" is sort of the other issue.
Bug 130041 is about putting fasl into cache folder. marking this one as 
dup of 169777.

*** This bug has been marked as a duplicate of 169777 ***

Comment 10

[Daniel Wang]

v

Comment 11

[Serge Gautherie (:sgautherie)]

(Removing 'Blocks: bug 134576', to clear things up there.)