User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 I have a 2.8 mbyte bookmark file. I have some entries near the bottom, which I am cutting and pasting multiple bookmarks (10-50) higher up in the bookmark file. This typically takes 5-15 minutes of elapsed time, and performs 24,000 i/o writes. CPU usage is typically 10-20% on a dual pentium-3 933, with 1 gig of ram. The disk being written to is a 15k rpm ibm scsi-160 drive, with over 50% free space. This slow performance is unacceptable. Reproducible: Always Steps to Reproduce: 1. Open bookmark file, scroll to bottom 2. select 20-50 bookmarks, cut 3. move up in bookmark file, paste Actual Results: 5-15 minutes of elapsed time, and well over 10,000 i/o writes Expected Results: It should be able to cut and paste in well under a second. If there are file i/o's, there should be much less. The bookmark file should be in ram, and occasionally flushed out to disk. Flushing to disk should take less than 1 second, and should be done in the background. Additionally, the 'search' for bookmarks should also be possible to do in the main bookmark window, which would make it easier to manage large bookmark files. Due to the performance bug and the lack of inline searching, I usually use emacs to manage the bookmark file. It worked much better and faster with netscape 4.x

Looks like a duplicate of bug 62907. Reporter, do you have a lot of bookmarks in the root folder? Caution. Read this bug before proceeding: bug 192124, and make a backup of your bookmarks.html. If you move many or most of the bookmarks out of the root folder and into child folders, does that improve the speed? Read bug 192124 before proceeding.

More importantly, are you still seeing this with a recent build (like 1.3b)? I think a fix went in recently that should drastically cut down on the number of i/o operations bookmarks perform. I could be wrong and the patch could still be under review, though....

I read bug 62907, and my bug seems different. They reported that bookmarks were slow to access, I reported that cut and paste took 5-15 minutes. I also read bug 192124, and my bug is different. I am not adding bookmarks to a newly created folder and having problems saving them. I have not tried 1.3b yet. I will give that a try soonest. I do have several bookmarks in the root folder. Perhaps 100 - 200. I have not tested how fast it is to move non root bookmarks around. However, my problem is not the bookmarks get lost, but that the process takes many minutes.

Jeff,a re you still experiencing this problem with Mozilla 1.3?

Resolving due to lack of response from reporter please reopen if the problem persists with a new build of Mozilla

I am running mozilla 1.5 on winxp pro. I submitted the bug. I did this again, and the problem still exists. It has taken about 25 minutes of cpu time, and my vm size is 394mbytes. The operation is still in progress, and the cpu and vm size is still growing.

My current bookmark file is 3.6 mbytes. 40 minutes cpu time and 699 mb of vm. Still crunching... It eventually crashed...

Duplicate based on reporter's statement in comment 3. Reporter, you can work around this problem by keeping the root folder in your bookmarks free of bookmarks. Store all bookmarks in folders. Bada bing. *** This bug has been marked as a duplicate of 62907 ***

Well, when I click on bookmarks->bookmark this page, it puts the bookmark in the root folder. So it seems there is no way to get it out of the root folder. Also, simply adding a folder inside another folder sometimes results in the runaway memory/cpu situation. This bug is not resolved, 1) it wedges mozilla. 2) it corrupts the bookmark file. 3) it forces me to use emacs to edit my bookmark file. I consider this a very severe bug.

At worst, you could save the bookmark to the root folder, then move it to another folder. Dupe. Do not reopen again. Direct your concerns to bug 62907, not this one. *** This bug has been marked as a duplicate of 62907 ***