User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126 I am experiencing much slower window close in the 1.2 release than in any previous versions. It now takes about 2 seconds to close a window and hard disk thrashing is seen. Closing a Tab is still instantaneous. Reproducible: Always Steps to Reproduce: 1. Press Ctrl-N 2. Close the new Window 3. Actual Results: Window close is much slower.

I can confirm this behaviour (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126). It started after changing from 1.2beta to 1.2 on Linux. Tabs are not affected but any browser-window including windows opend by JavaScript. There are about 2 seconds of heavy harddisk activity before the window closes. Mail- or Composer-Windows are not affected. Going to test it on a windows machine to post the results here later.

Tested on Windows 98 with 1.2 Though having less experience about close-window-behaviour on Win98 with versions of Mozilla prior to 1.2, closing windows also seems delayed here. Yet it is less ovious and with less harddisk activity. Can this be due to different harddisk-chaching of win98??? On Linux I use the ext3 file system. Is it possible that Mozilla 1.2. does some harddisk operation causing ext3 to perform very slow?

Remounting my home partition as ext2 does indeed lessen the close delay and disk activity. But it still takes about 1 second to close a window. Hardware: IBM TP20, PIII 500, 128M SDRAM. There was no disk activity when closing a browser window in previous versions of mozilla.

worksforme with linux trunk build 20021126 and 1.2 release if you check Mozilla's memory usage with top, is it using a lot of RAM? (or is there something else eating a lot of RAM?)

On my system with 256 MB physical memory installed Mozilla is using 29 MB, X is using 42,2 MB, these are the big ones. System Monitor shows 160 of 256 MB used. Swap-Memoriy 0 of 512 MB used. (Redhat 8.0 with KDE-Desktop)

The comparisons between 1.2 and previous releases were done under the same conditions. The memory usage of 1.2 is normal: $ ps aux ... wenzhuo 1091 0.0 0.8 2260 1044 tty1 S 10:02 0:00 /bin/sh /home/wen wenzhuo 1097 12.2 22.2 49492 28476 tty1 R 10:02 0:04 /home/wenzhuo/moz wenzhuo 1099 0.0 22.2 49492 28476 tty1 S 10:02 0:00 /home/wenzhuo/moz wenzhuo 1100 0.1 22.2 49492 28476 tty1 S 10:02 0:00 /home/wenzhuo/moz wenzhuo 1101 0.0 22.2 49492 28476 tty1 S 10:02 0:00 /home/wenzhuo/moz wenzhuo 1102 0.0 22.2 49492 28476 tty1 S 10:02 0:00 /home/wenzhuo/moz wenzhuo 1107 0.0 22.2 49492 28476 tty1 S 10:02 0:00 /home/wenzhuo/moz wenzhuo 1108 0.2 22.2 49492 28476 tty1 S 10:02 0:00 /home/wenzhuo/moz wenzhuo 1109 0.0 22.2 49492 28476 tty1 S 10:02 0:00 /home/wenzhuo/moz ... $ free total used free shared buffers cached Mem: 127768 97720 30048 0 9916 53112 -/+ buffers/cache: 34692 93076 Swap: 264592 0 264592

neither one of you is seeing particular high memory usage. 30-45 MB for Mozilla is quite reasonable. If you have lots of free RAM, Linux will use it for disk cache, so it doesn't show up as "free". I don't know of any other reason that it would take long to close a window.

However this effect persists and is strongly reducing perceived speed of Mozilla when working with various windows.

I think Bug 182472 and Bug 101319 are related. I noticed the same harddisk activity when dragging a new bookmark into the sidebar as it occours when closing a browser window. Maybe the harddisk activity is what is described in Bug 182472. Has there been some change between 1.2b and 1.2 in how to handle the bookmark (or some other preference-) file with browser-windows that are _not_ the last Mozilla window?

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 Window close time has increased significantly from 1.2b to 1.2. The delay appears to increase linearly with the size of the bookmarks file. The bookmarks are written to disk when a browser window is closed. Mozilla 1.2b did the same, so I guess it's supposed to do that and this by itself is not the problem.

Me too - Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2) Gecko/20021126 Going from 1.2b to 1.2, totally new and ugly phenomenon of noisy hard disk activity on closing a browser window. If Bookmarks.html and localstore.rdf were being written at this point in 1.2b, then the disc activity must be caused by something else, because I wasn't experiencing this with 1.2b

does this problem occur with a clean profile? how big are the bookmarks, localstore.rdf and history.dat files (all of these are written on window close)?

The problem occurs with a clean profile. I copied and repeatedly pasted the "Mozilla Organization" folder to increase the bookmark file size to about 500kB. After that, closing a window takes about three seconds on my system. Mozilla 1.2b handles bookmark files of that size much faster. The effect is noticeable with a smaller bookmark file. Closing tabs is unaffected. Quitting Mozilla (closing the last window) also takes much longer than with 1.2b. The window vanishes at once, but the time for cleanup (until the process is gone) has increased.

Harddisk activity on closing windows occured immediately after changing to 1.2 from 1.2b, which means using e.g. the same bookmark-file. Clearing the browser history won't help.

this appears to be a dupe of bug 101319, which also mentions a perf regression bewteen 1.1 and 1.2 however, I tested this myself by making 10,000 dummy bookmarks. time to open and close Mozilla (P-II 450, Linux): 1.1: 13s 1.2: 13s trunk (20021129): 90s I'll try to narrow down the regression a bit more, but I'm not seeing the same thing you are. ==> Bookmarks

I filed bug 182842 for what I was seeing. This bug can be duped against bug 101319 or used to figure out why you guys are seeing a 1.1 => 1.2 regression.

The regression between version 1.1 and 1.2 is caused by the number of read and write operations to bookmarks-1.html. In 1.1 this is a handfull, in 1.2 I have logged about 50 read and 500 write operation to bookmarks-1.html. I used the freeware utility FileMon from www.sysinternals.com.

*** Bug 183187 has been marked as a duplicate of this bug. ***

*** Bug 183257 has been marked as a duplicate of this bug. ***

*** Bug 183634 has been marked as a duplicate of this bug. ***

*** Bug 183713 has been marked as a duplicate of this bug. ***

*** Bug 184190 has been marked as a duplicate of this bug. ***

As this bug annoys the hell out of me I have done a little research of my own. Here's what I found: First a log of all file operations while closing a browser window under Windows XP Professional revealed that that the bookmark file gets written in chunks of 4KB at a time. Nothing wrong with that. But I also noticed that each write is immediately followed by a flush to disk operation. Which when I logged time duration of the file ops as well, proved to be the main reason for the slowdown, with ~50ms for each flush on my system. Next I downloaded the tarball for mozilla 1.2.1 (my currently installed version) and browsed the source. The file operations for the bookmark file are done using the nsOutputFileStream class defined in C:\Projects\mozilla\xpcom\io\nsFileStream.h The actual implementation for the file-stream seems to be in class FileImpl. I noticed that on every call to FileImpl::Seek() and for every filled buffer (set to a size of 4096 bytes) in FileImpl::Write(), FileImpl::Flush() gets called. A closer look at FileImpl::Flush() reveals the lines if (PR_Sync(mFileDesc) != PR_SUCCESS) mFailed = PR_TRUE; at the end of the function. I was able to trace this down to the function PRInt32_PR_MD_FSYNC(PRFileDesc *fd) in file mozilla/nsprpub/pr/src/md/windows/ntio.c where the Windows File I/O operation FlushFileBuffers() gets called. Now the MSDN documentation for FlushFileBuffers contains this remark : "The WriteFile and WriteFileEx functions typically write data to an internal buffer that the operating system writes to disk on a regular basis. The FlushFileBuffers function writes all of the buffered information for the specified file to disk. " Finally I grabbed a copy of the source tarball for mozilla 1.2b, the last one that did not show this behaviour and did a file compare with the mozilla 1.2.1 sources What I found what this change in one of the the relevant sources: mozilla\xpcom\io\nsIFileStream.cpp, Line 558, mozilla release 1.2b #ifdef XP_MAC // On unix, it seems to fail always. if (PR_Sync(mFileDesc) != PR_SUCCESS) mFailed = PR_TRUE; #endif as compared to: mozilla\xpcom\io\nsIFileStream.cpp, Line 558, mozilla release 1.2.1 if (PR_Sync(mFileDesc) != PR_SUCCESS) mFailed = PR_TRUE; It seems to me that the removal of the above #ifdef caused this bug.

thanks Boris! see http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpcom/io/nsIFileStream.cpp the changes you mention were made Nov 11 (bug 142196). on November 20, Flush() was reworked because of performance problems with attachments (the bug number there seems to be wrong). so, if that's the problem, it might already be fixed on the trunk. unfortunately, the trunk has bigger problems (bug 182842), so switching to a trunk build will probably just add to your pain.

The OS should be "All" because all systems are affected (see comment 23).

*** Bug 184577 has been marked as a duplicate of this bug. ***

*** Bug 184867 has been marked as a duplicate of this bug. ***

*** Bug 182435 has been marked as a duplicate of this bug. ***

*** Bug 182472 has been marked as a duplicate of this bug. ***

*** Bug 182619 has been marked as a duplicate of this bug. ***

I also get lots of disk thrashing when closing open Mozilla Windows (but not tabs) in Mozilla 1.2.1 on Windows 2000/SP3 on my dual P-III/500.Mhz w/512.Meg RAM. I didn't have this problem in Mozilla 1.1, which closed much faster. (My Bookmarks.html file is 180.K)

I was seeing this in 1.2, as per comment #11, and also in 1.2.1. But the problem seems to have disappeared in 1.3a - when bookmarks are written on closing a browser window, the thrashing no longer occurs.

wfm on 1.3a (200212 1215) on Win2K I did see the problem on 1.2.1 on Win2K.

If this is still a problem we should get it fixed for 1.3beta.

Also Works for Me with 1.3a on Windows 2000.

Nominating for nav triage consideration. This is on Asa's list for 1.3 beta.

Nav triage team: nsbeta1+/adt2

FWIW: this was probably fixed by bug 180516 (based on the analysis in comment 23). users of trunk builds (1.3a and on) have not reported a problem here.

Does anybody still see this bug? If not -> dupe of bug 180516

if this was still happening, I'm sure we'd here about it. marking dupe *** This bug has been marked as a duplicate of 180516 ***

*** Bug 191264 has been marked as a duplicate of this bug. ***

*** Bug 191293 has been marked as a duplicate of this bug. ***

*** Bug 196800 has been marked as a duplicate of this bug. ***