Closed Bug 61994 Opened 24 years ago Closed 24 years ago

Old profile decreases perf a lot

Categories

(Core :: DOM: Navigation, defect, P3)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 61140

People

(Reporter: BenB, Assigned: alecf)

References

Details

(Keywords: perf)

Attachments

(1 file)

profile_results.zip, profiling results fast and slow
94.90 KB, application/octet-stream
Details
<quote src="bug 49141"> ------- Additional Comments From Jens-Uwe 2000-12-05 03:14 ------- is there still someone working on this? the latest nightlies are taking 5-10 secs for creating a new window, and thats on a P3-550 with 256MB. And within this time Mozilla seems completly blocked :-/ ------- Additional Comments From Eugene Savitsky 2000-12-05 04:02 ------- Try out with a new profile. When I convert from NS4 I get 1-2 sec for new window, but with a clean profile they take 2 times quicker. PS The time also depends on how long mozilla was running - afret half an our and many sites visited it takes ~40Mb and more... ------- Additional Comments From Jens-Uwe 2000-12-05 04:51 ------- Eugen: Thanks, it is much faster now. Seems there were some old datas left in my directories :-) Anyway, its still not fast enough ;-) </quote> That's something very wrong, if migrated (or long-used) profiles make Mozilla considerably slowlier. Eugene, Jens-Uwe, please describe your migrated profiles and make some guesses what could be the reason.
Keywords: perf
Summary: Migrated profiles decreases perf a lot → Migrated profile decreases perf a lot
migration?
Assignee: asa → dbragg
Component: Browser-General → Profile Migration
QA Contact: doronr → gbush
This would not be migration. Migration just copies files from the old profile to the new profile location. It makes a few small, mail-related changes to the prefs.js file but that's the only changes it makes. It would be a browser bug relating to how the browser reads the various migrated files (prefs.js, security files, etc). I don't see how the files themselves could make the browser fast or slow. Sorry to do this to you Asa but I really think this is a browser problem.
Assignee: dbragg → asa
I tend to agree. After reading the above comments I went and deleted a bunch of stuff (History for instance was about 1.5meg) from my non-migrated profile and noticed new window performance to improve considerably.
Summary: Migrated profile decreases perf a lot → Old profile decreases perf a lot
Ben: until yesterday I used a old grown .mozilla directory (I am on linux). It was perhaps 1-2 monthes old, and opening a new window took about 7-10 seconds. Then yesterday, after reading Eugenes comment, I removed the .mozilla-directory and was asked to create a new one, either by using the Old NS4-settings or new ones. I tried both ways and noticed an HUGE speed up when opening and closing windows (1-2 seconds). I think it is faster with new settings compared with using NS4 setttings, but I am not sure! It might be, that the settings in the .mozilla-directory grow and grow with the time, slowing mozilla down, always a little bit so one does not notice it until it simply gets annoying... Phil Sweeney's comment seems to support this.
In the attachment above you find my profiling results for opening and closing windows, measured with jprof (./configure --enable-jprof, so I guess with debugging on and optimizing off) and a version from the 3rd of december. "slow" was measured with an long used profile, while "fast" was measured with a new created profile. There is a huge difference between the slow and the fast version, which explains the speed loss. In the slow version most of the time (>90%) is spend in functions called "morkXXX" (see mozilla/db/mork/src), while this routines are not called at all (or atleast they take nearly no time) in the fast version. Does somebody knows, what these "mork"-function do and why they are called when opening or closing a window? Either speeding this up or removing the call to them would cause an HUGE speed up for opening new windows!!!
Jens-Uwe, thanks for your work. Mork is the database Mozilla uses. Mainly for Mailnews folder summaries, but I guess for history, too. REASSIGNing to bienvenu, who owns Mork, IIRC.
Assignee: asa → bienvenu
Severity: normal → major
Component: Profile Migration → History
Keywords: mozilla0.9
Does history grow without bounds? Is the history db opened and closed for every window? Those would be things outside my control, I'm afraid.
Assignee: bienvenu → alecf
adding self to cc list - my history db is 3.5 MB, which seems to imply that history does grow w/o bounds - I don't think previous versions did this.
history expiration is totally unimplemented! :-( There's probably a bug on this somewhere. Anyway, I'm almost finished coding up some history code to implement expiration when we close the history db - I'll attach it when I'm finished.
bienvenu, feel free to take bug 55293 :).
Depends on: 55293
No longer depends on: 55293
Stepped over my own changes, sorry. Readding 55293 as blocker.
Depends on: 55293
resolving as dup of 55293 *** This bug has been marked as a duplicate of 55293 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
I'd rather leave this open, since we don't know, if the history is the only cause for the slowdown. You want to close it, OK. But do not verify until the other bug is fixed and it is proved that the problem initially stated in this bug is fixed.
I agree with Ben, are we sure this is a dupe of the same bug? I was wondering if there was something else lingering. Should we really go that much slower just becase we have a larger histroy to drag around. Was NS4.x like that? It seems like there could be a way we could be more effecent even if the bug is becase we are dragging a huge history around with us. Are we aure we are not also converting other garbabage that we don't need to that is causeing other slowness?
I'm pretty damn sure that the time to read a 3.5MB file into memory instead of a 50K file is a pretty signifcant performance problem, but if you want to test my theory, just Clear your history using the prefs UI, and see if that improves your startup time. History in 4.x did not grow w/o bounds - by default, it kept history for nine days. I can't tell that 6.0 has a default, but since it would have ignored it, I guess it doesn't matter.
I was more curious why I a don't see the quite the same slow down with a large history in NS4.x as we are seeing in Mozilla. That is why i wondered if we were being effecent.
How large is your 4.x history file? 4.x, by default, only remembers your last 9 days of history - 6.0 remembers history *forever*, so the history file can get much much bigger.
NETSCAPE.HST 5,611,520 set for 25 days as i like to know where I have been :)
I don't know how 4.x history files are read into memory - it's possible that something less than the whole file is read into memory (e.g., perhaps just an index of the urls in the history file is read into memory). But I'm sure that aging history databases is going to help a lot with the load time of the first browser window (subsequent browser window opens are not affected by history size, since the db is only opened once.)
> (subsequent browser window opens are not affected by history > size, since the db is only opened once.) Doesn't this suggest that this is *not* a dup? Reporters spoke about "new windows", so I assume the browser ran already and they opened additional windows. asj, I suggest to file a new bug about Mozilla's history being appareantly being much slowier than 4.x'.
If they're blaming the opening of a second browser window on the history code, then they are probably barking up the wrong tree, as near as I can tell, since no history code is run.
How do you explain Jens-Uwe's profiling results, then?
My guess is that Jens-Uwe's measurements were taken on opening the first browser window, not opening the second browser window. But don't take my word for it; use your favorite debugger, open a browser window, set a breakpoint in nsGlobalHistory::Init, or better yet, nsGlobalHistory::OpenDB, and then set a second breakpoint and see if your breakpoint gets hit.
Jens-Uwe's results may also have been because his history was corrupted, and every time we accessed the history service we would try AGAIN to open the history DB. that is bug 61140, which I have a fix for (just awaiting a review)
bienvenu is correct though, that history expiration is not implemented (i.e. bug 55293) and that this would slow down the opening of the first browser window. I'm verifying dupe based on this.
Why is history being accessed for new windows? As far as I know at the moment Moz doesn't inherit back history, so I don't see any reason why it should. Even when it does I would hope it would only need to look at things which are all in memory. One should be able to have an efficient browser and big history and not have to rely on truncating history.
Whoops sorry I must have missed some more recent comments ...
bienvenu: I thought I measured "open new window", means I had a windows open and opened a second one. The mork-routines are indeed not called now, so I would like to know, where jprof got its results from. But thats a different story and does not belong to here. Sorry... I'll check that out, hoping to find the real reason for the slow new window.Anyway, we should reopen this bug, since its now not a duplicate of bug 55293 any more!
REOPENing per Jens-Uwe's comment.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Matthew: we're talking about global history (i.e. which uses Mork) not session history (back/forward) Jans-Uwe: would you please try deleting your history.dat from your "slow" profile, and starting again? As I have already said above, I'm pretty sure your history is corrupt, and that it is trying to re-read your history file every time it opens a new window. That is why this is a dupe of bug 55293, and bug 61140 I'm re-closing this as a dupe of 61140 to appease Ben... until you try this, everything points to this issue. *** This bug has been marked as a duplicate of 61140 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
changing QA contact.....I think this belongs to you----
QA Contact: gbush → claudius
mass-verifying Duplicate bugs which haven't changed since 2001.12.31. set your search string in mail to "CitizenGKar" to filter out these messages.
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: