***Overview Description: Maybe you already know this and are tracking it elsewhere. I was just going to write up a new bug because processing drops also seemed inordinately slow(maybe a pink bug?) but i came across these comments in bug 23298 and thought it might be systemic: ------- Additional Comments From jb@as220.org 2000-03-21 07:59 ------- OK, as of cvs-build 10am edt 3/21, I'm not seeing a crash. The bookmark-manager window is still troubled: it takes about 30 seconds of 100% k6-2/350 cpu to do anything: drag, create, delete. These same operations complete in say 5 sec of cpu when done in the bookmark sidebar. Assuming that the same code is doing the actual bookmark ops, and given the marked difference between time in the sidebar and in the manager window, I suspect there is the equivalent of a nearly-infinite loop in the rendering code for the manager window.

I did a CVS build last night (bookmark sidebar weird, duplicated) and just checked bookmark-manager window. Tested a change-properties on a bookmark, changing the same. This completed in a fairly timely manner, but is one of the things that cause mozilla to burn 100% cpu thereafter, and of course operate more slowly. I noticed when I killed it after that it only got down to WEBSHELL -= 9 on the way out... anyways, it might be fixed: my current CVS build (5:30 pm EDT 4/7) finished and I tried that. No infinite CPU, worked OK, finished at exit with WEBSHELL -= 0. Bookmark sidebar went from duplication to blank, and I think the URL window still isn't updating right, but those are other issues. Debian/unstable, K6, SGI CVS-build Linux system.

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

claudius...how does this look with today vs. PR1?

First off, the bug here is not just 'bookmarks are slow'. It's that manipulating them in the Manage Bookmarks window is slow compared to manipulating them in the sidebar - which should be the same exact thing. As far as vs. PR1 my rudimentary testing says that we don't seem to be any slower now (Linux PR1 vs. Linux Tip on a 133mhz) but Manage Bookmarks may still be slower than the sidebar (WinNT Tip on a 400mhz machine). Bug 38749 (no bookmarks in sidebar)has made full evaluation difficult. jb@as220.org did some work on this and may be able to add more to the current status. Jim??

Putting on [nsbeta2-] radar. Thanks claudius!

The boomark manager window is still pretty bad in general, and drag-and-drop is still very slow, burning straight CPU on my k6-2/350 for maybe 7 seconds. The sidebar takes about 2 seconds of straight CPU to do the same thing. Current CVS build, current Linux.

jb, does it take 7 seconds to complete the D&D gesture (visually, to the user), or is your CPU just churning for a while after the gesture in completed? I ask because it doesn't seem to take even close to that long on my P133 --but then again I'm not looking at CPU usage.

It takes about 7 seconds of CPU burn to complete visually. The CPU burn stops when the moved bookmark shows up at the new location.

Ihere are some crappy O(n^2) (and worse!) algorthims that are happening here. It probably is heavily dependent on the number of elements in the source and target folders. To fix this properly, I think we need to make a s3kret interface that a datasource can implement. This interface would allow the RDF container utilities a "back door" around the O(n^2) stuff if the datasource supported it.

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

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

adding a data point from bug 45001: ------- Additional Comments From devotip@tiscalinet.it 2000-07-10 17:49 ------- Actally it's not frozen. When deleting a folder containing bookmarks it takes about 4 seconds for every bookmark, On an athlon 750 with 128 megs (win98 build 20000071008)

I have some ideas here. If somebody else wanted to tackle this, I would love to talk to them about it.

I'll be in tomorrow (Friday)... be happy to.

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

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

to rjc, per our conversation yesterday.

triage team: [NEED INFO] Is this associated with the slow performance in deleting and moving email messages? If so, we should jump on this. If not, we could live with just adding cursor feedback to let the user know that the product is not frozen. cc'ing matt since he is working on other cursor feedback issues.

mail bug that may be related: bug 17470

Fixed (by zany usage of waterson's exposed begin|end-update-batching)

I hope this really works. I've had people tell me that bookmarks just "don't work" in PR2 due in part, I believe, to this slowness.

> I hope this really works. Have faith. Feel free to provide some hard timing data. :) On my Mac, an operation that took over 10 minutes [bookmark folder with about 800 items, drag&drop a new bookmark to the start of the list of 800] took less than a second after the changes.

I have seen the light and iknow belive! VERIFIED Fixed 2000113004 builds