131130 - perf problem closing windows with large bookmarks file with slow cpus, integraded graphics, and slow hard drives

Status: RESOLVED DUPLICATE of bug 101319

(SeaMonkey :: Bookmarks & History, defect)

Description

[[not reading bugmail]]

I started noticing more often that mozilla tends to take more time each day till
I noticed it was a real problem the otherday.  I have a bookmarks.html file that
is now 590K in size.  When I close a mozilla window with more than one window
open.. I  get a ~4 to 5 second hang that appears to be a disk thrash.. as I wait
I cannot use another app really.. and as I have the profile/xxxxxx.slt/
directory open to view I notice that bookmarks.html file was being written to
every time I closed a window, using both 'x' cross, and file> close window..
this is really starting drag performance.. 

expected: see if we can write bookmarks.html sometime at random intervals during
a browser session, or say some arbitrary number of bookmark additions if we are
doing this to keep the bookmarks file as up to date as possible.  or just write
it upon closing Mozilla down once.

Comment 1

[[not reading bugmail]]

nominating for end users.. 

I was thinking this maybe a XP type component issue, didn't think it was
actually file handling.. but its like an event that takes place. So I chose
event handling.

Feel free to punt as necessary to get where we need to be if you know where this
goes.  I dont know which it is suppose to be in.  Thanks.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Um... This is "Bookmarks".  We do this for good reasons (so that bookmarks
always get saved before app exit, for example).

Comment 3

[[not reading bugmail]]

thanks boris.  I seen this problem today that would hopefully not happen if I
close a window using 'x' cross button.  bug 128461.  While the bookmarks are
loaded in memory they are not being correctly modified if they already exist.  I
noted in that bug that I had to delete a bookmark instead of modifing it, and
then exit Mozilla anyway just to get a properties element to write to the
bookmark file, then   re-bookmark the new link to that folder when it came back
up.  something that may block this bug if it is a real issue when closing a window.

Comment 4

[[not reading bugmail]]

note: hoping that freeing memory fix will help this problem; see bug 126107.

Comment 5

[[not reading bugmail]]

maybe the trick we add here is only write it on closing a browser window.. cause
I see this for any window.. download manager, mailnews, addressbook.. which none
have bookmarks..

But, I'd really like to see just write once during your session ie the last
closed mozilla window on Exit (shutdown of mozilla) regardless of the # of
browser windows the user has open.  This I dont mind.. but between.. on every
window is a bit excessive I think.

Comment 6

[[not reading bugmail]]

I figured out something here with my own system.. somehow: my 7200 RPM IBM
75GXP, UltraDMA 33 drive was set on PIO Mode.  I had to re-install the Primary
IDE channel Driver to get it to run in Ultra33 again..  this caused this ~4 to
~5 second writing of bookmarks.html file on a 733-P3.. and it appears to stop
Mozilla in its tracks with creating XUL and focus issues.  Setting it back to
Ultra Dma 33, allows it to write to disk as my video & CPU update mozilla's UI
with minimal < 1 sec performance impact.

Now, this performance drop from this issue implies that slow hard drives cause
mozilla to be slow because its got to write the bookmarks.html file out, because
integration plagues the CPU & Video at the same time so it cannot multi-task.

this is the same kinda of performance issue with Celeron 550 with integrated
video chipset with 64meg ram with UltraDMA 100, Maxtor 5400 PRM 40gig platter
drive has.. 

so writing the bookmarks.html file out is causing performance issues when
closing windows that are very noticeable and lock down Mozilla & the system till
this is done.

Comment 7

[Peter Trudelle]

nsbeta1-, ->1.2

Comment 8

[[not reading bugmail]]

Just modifying summary.. 

Comment 9

[Andreas Kunz]

I think this is a duplicate of 101319 (or vice versa).

Comment 10

[Boris Zbarsky [:bzbarsky]]

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