Old profile decreases perf a lot




19 years ago
11 years ago


(Reporter: BenB, Assigned: alecf)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)

<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 -------
Thanks, it is much faster now. Seems there were some old datas left in my
directories :-)
Anyway, its still not fast enough ;-)

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
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
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 ***
Closed: 19 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 

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.

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

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 ...
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.
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 ***
Closed: 19 years ago19 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.
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.