Post 1.4a builds hang for about 10" every time a browser window is closed (spinning wheel, 90% CPU). This time is mostly spent writing bookmarks, according to Sampler.app (see attached report), so the bookmarks code of April 2 seems a likely culprit: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp

Using build 2003-04-17-03. Sampled evey 10ms from just before closing a window, until CPU usage settles under 10%.

To see this bug you need a large bookmarks file, e.g. this one (350 kB) will do: http://www.mozilla.org/xpapps/performance/tests/bookmarks.html The following steps seem to reliably reproduce the bug: (1) Have above bookmarks.html in your profile. (an otherwise brand new profile will do) (2) Launch Mozilla, open a browser window, close it. Results: Mozilla hangs for several seconds. Note: The bookmarks file format gets changed (with addition of tags like ID="rdf:#$pGtWV3") the first time it's rewritten to disk. Make sure this has happened, e.g. by bookmarking a few more pages. After that, my experience is that *every* window close, even after a Mozilla restart, causes the hang.

I see this in Bug 201562 Slow closing bookmark menues after adding bookmark

Can you guys run Sampler or ThreadViewer and tell us where the time goes?

Simon: A Sampler report is attached to comment 1.

Whoops, thanks! Looks like nsBookmarksService::WriteBookmarks needs optimization.

Is this a windows bug also? I can't replicate this on my win2k build, but bug 201562 seems to indicate this is a problem on win98... cc'ing darin: right now, I have lots of little nsIFileOutputStream::Write() calls... would it be more efficient to combine these calls somehow? If so, how's the best way to do that? Is there a buffered output stream that would be more efficient?

Benjamin: when you tried, are you sure the big bookmarks file was converted to the new format? I've seen cases where it wasn't, and then I saw no hang. (I'm not sure what decides if it gets converted or not, but adding bookmarks, or moving some in bookmarks manager, seems to eventually force it.)

Windows XP case seems also confirmed by bug 101319, comment 36

Simon, I´m on Win98. Where can I get Sampler or Threadviewer, or is this Mac-Specific?

I think nsIBufferedOutputStream should improve perf significantly. I guess 32k for buffer should be sufficient.

Here is a potential fix. Can someone who can reproduce this build with this patch? Maybe my system is too fast or something, but I don't see a significant hang after managing the large bookmarks file or shutting down after deleting a bookmark.

Comment on attachment 120966 [details] [diff] [review] WriteBookmarks uses buffered output stream That looks like a good fix. We need some one more familiar with output streams to review it.

Comment on attachment 120966 [details] [diff] [review] WriteBookmarks uses buffered output stream r=darin

Comment on attachment 120966 [details] [diff] [review] WriteBookmarks uses buffered output stream sr=me. Who wants to check it in?

I do, along with bug 199872

checked in

reassigning to bsmedberg@covad.net, to give him credit for his patch.

Can someone who saw this problem VERIFY this?

2003041904 on Windows XP is the first nightly build in a couple of weeks to NOT have this problem (yay!) so I'd say, yes, the problem has gone for me.

Using build 2003-04-19-03, otherwise same protocol as in comment 1. Excellent! The hang is gone, Moz is found in nsBookmarksService::WriteBookmarks in 78 (versus the previous 832) 10ms intervals. Thanks Jan & Benjamin, for the ligntning fast fix!

Verified