Closed Bug 130322 Opened 23 years ago Closed 23 years ago

about:plugins takes a long time to complete

Categories

(Core Graveyard :: Plug-ins, defect, P3)

DEC
OpenVMS
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 109739
mozilla1.1alpha

People

(Reporter: colin, Assigned: serhunt)

Details

(Keywords: perf)

about:plugins takes about 20 seconds (on my fast system!!) before it displays the information about the plugins (all I have is the default null plugin). During this time a busy cursor is displayed but the throbber is not throbbing. I do not see this problem on M0.9.8 - this is certainly new to M0.9.9. Mozilla is doing lots of I/O and consuming quite a bit of CPU while this is going on. I haven't been able to determine what the I/O is yet. Second and subsequent about:plugins do NOT see this delay. So if it is I/O that makes the first occurence slow, all the data must be getting cached somewhere. Any idea what could be happening? OpenVMS does have a slow file system when its doing some of these UNIX'y things such as opendir/readdir. Any ideas where I should be looking? What's changed in the way about:plugins works between 0.9.8 and 0.9.9? Colin.
my wild guesses: 1) fix for bug 45699 definitely should slightly decrease performance because we added an additional directory (~/.mozilla/plugins) to scan in. 2) could be a problem described by bug 109739, ~/.mozilla/appreg is getting too big.
checked the size of my ~/.mozilla/appreg, which was last created on march 3rd: it had grown to 1474208 bytes. about:plugins took 8 sec. (I've seen appreg at 20 times that size, and with less plugins) Deleted appreg, faked recreating of profile (with the old name): New appreg was 29959 bytes. about:plugins took 6 sec. The file increments as happily as ever, for each run of a "different" mozilla, *regardless of the timestamp on plugins*. I now have them all in ~/.mozilla/plugins, where they haven't been altered since March 3rd. I have two CVS builds, and tested appreg growth-rate just for fun now: Starting mozilla from build-1: appreg freshly created: 29959 bytes. Quit moz, started CVS build-2: appreg grew to 87369 bytes (!) Quit moz again, started build-1 again: appreg grew to 116074 bytes. etc. etc. etc.
You're right, it does appear to be related to the size of the appreg file. I have two different user trees. user1 - appreg is 267kb - about:plugins takes 20 seconds user2 - appreg is 8kb - about:plugins takes <1 second Of course, there are other differences in the user trees so I can't confirm that appreg is definitely the culprit here. The strange this is, M0.9.8 is fast even with the 267kb appreg file. Were we not reading appreg before M0.9.9?
Keywords: perf
More info. During the 20 second "hang", there is a LOT of disk activity. I can't determine which file is being hammered (no open() calls or readdir() calls are occurring) but I know its something in the installation tree and NOT the profile dir. At this point mozilla has many file open in the inst tree. Now sometimes I get a crash at the end of the hang. So I fired up my debug version of 099 to see what was happening, and then runs just fine. Same profile, and about:plugins there takes less than a second. I think we have some unitialised data somewhere? Still trying to track it down...
moving to 1.1
Priority: -- → P3
Target Milestone: --- → mozilla1.1alpha
I found out WHERE we're spendind the 20 seconds, but I don't know WHY its taking so long. We're in nsStaticComponentLoader::AutoRegisterComponents, and its going around the for loop 89 times (once for each static component?) that takes the time.
Serge, you were right in part two of comment #1. My appreg file is 334K. If I run the same mozilla from a much newer user account where the appreg file is only 16K then it zips right through the 89 loops in nsStaticComponentLoader::AutoRegisterComponents. But that's not all. Not only is size of appreg very different between my two accounts, but the results of the calls to RegisterSelf are different too. With the new account where appreg is small, each RegisterSelf call returns with 80510008 (NS_ERROR_SCHEMA_FACET_VALUE_ERROR??), whereas with my older account where appreg is larger, each RegisterSelf call is coming back with a 0. Is this anything to do with the fact that several versions ago OpenVMS used to do a shared libs build, but now its doing a static build? Do I have some old crud in my appreg file? How can I purge the old crud out of my appreg file without losing any user profile stuff?
This is most likely a dup of appreg bloat bug. Marking. Please reopen if disagree. *** This bug has been marked as a duplicate of 109739 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
mass duplicate verifications . For filtering purposes, pls use keywd "massdupverification"
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.