User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.13) Gecko/20080325 Ubuntu/7.10 (gutsy) Firefox/2.0.0.13 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040705 Minefield/3.0pre Some operations like "Paste", "New bookmark...", "New Folder..." and "New Separator" are very slow in the library under certain circumstances. I have circa 3500 bookmarks in 250 folders and these operations take circa 10s with 100% CPU on the top level (Bookmarks Menu) in the library. (My system: Ubuntu 7.10, Windows XP, Athlon XP2500+, 1GB Ram) These operations are almost instantly in the bookmarks menu, or on the deepest folder levels in the library. The attached test file shows a similar bad performance like my normal bookmarks. I tried some different configurations and the performance seems to mostly depend on the number of folders on the current level and below, the number of bookmarks had a much lesser influence. Reproducible: Always Steps to Reproduce: 1.Create a new profile and import the bookmarks.html test file 2.Open the library 3.Copy bookmark "bookmark_2580" 4.Paste it on the same level Actual Results: The browser hangs for some seconds Expected Results: It should be fast like in the bookmarks menu

Another performance problem, probably related to the problem described above: Sometimes firefox hangs not only 10 seconds, but some minutes with 100% CPU and a fast rising memory use, if i copy/ cut and paste bookmarks in the library. I can reproduce this only with some bookmarks, it doesn't happen with disabled microsummaries (browser.microsummary.enabled false) or only a small number of bookmarks. STR: 1.Like step 1 in comment 0 2.Visit http://www.webstandards.org/2008/04/07/acid3-passed-in-23-days/ and create a bookmark for the site one position under "bookmark_2589" 3.Open the library 4.Copy bookmark "bookmark_2580" 5.Select the bookmark "Acid3 Passed in 23 Days! - The Web Standards Project" and choose "Paste" from the context menu The same operations are fast in the bookmarks menu.

So it's ALWAYS fast with microsummaries disabled?

No, it always hangs for 10 seconds with microsummaries disabled.

so you always have a slowdown, but with usummaries enabled it is worst?

Yes, but the extreme slowdown with microsummaries enabled is not general. For example with the pure test file it makes no difference, if they are enabled or not and in my normal profile i only see this with some bookmarks.

bug 420078 would likely help here.

I don't know if it's useful in this case, but i've found a regression range. Builds before the regression range do not hang with the steps from comment 0 and comment 2. Regression range: works: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020604 Minefield/3.0b4pre hangs: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020613 Minefield/3.0b4pre Bonsai query: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2008-02-06+04&maxdate=2008-02-06+13%3A59%3A59 In the steps from comment 2 it's necessary to close the site after step 2.

I'm supporting this bug report with my observations: * Deleting one bookmark seems to be slower than deleting a group of bookmarks. * Even just opening a folder may take one second. * Deleting an empty folder takes a second, too. However, deleting a folder which is not empty is absolutely ridiculous, it may block for more than half a minute. * Bookmark import is incredibly slow, too, and almost blocks my PC. Is this related to the database approach of the new bookmark system? I have not seen any good reason for this change, and I don't think Mozilla should follow the footsteps of Microsoft, putting improved hardware performance to death by increasing the complexity of features without real need. Like https://bugzilla.mozilla.org/show_bug.cgi?id=435060 which was marked duplicate of this one, I do consider this problem at least major, not minor!

+1 from me. Let me know if i can provide some data. Much slower that FF2. And clicking especially. This is really bad experience. My colleagues have installed FF3 (with my advise). And now all of them are complaining.

What i have found to be the slowest is making new folders. It is pretty quick at the top of my folder chain, but very slow at the bottom. Making bookmarks is fast in either case. I do this all in the sidebar, if that matters. I did like the html file for bookmarks, so I too am curious why it was switched to a database.

Not going to block on this particular bug, but making dependent on bug 432706 which is blocking, and should mitigate the problem here (potential 80% perf improvement). Let's re-evaluate blocking status of this bug after that one lands.

See https://bugzilla.mozilla.org/show_bug.cgi?id=432706#c40: > Considering the symptoms that have been reported, > I would hope for an improvement of 800% rather than 80%, > otherwise the bug is not really fixed. > ...

Can folks test latest nightlies and report any pain points back here?

Here you go... Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090109 Minefield/3.2a1pre Pain point -1 I have imported bookmarks from existing profile (around 1000). I am trying to oraganize them in "library" view. If i click on any of subfolder (Subfolders have less than 15 bookmarks on average), It takes around 2-3 seconds to open folder. This gets worst if subfolders have other subfolders and more bookmarks. (around 4 -5 seconds) But if i do same action from left tree view its less than a second.

Jigar, so the problem only occurs when double-clicking items in the list on the *right*?

Yes...but its dramatically fast when i select it from tree view(Left navigation).

Can this be added to 3.5 sprints ? Looks like its same issue as B405765. In fact, It has a patch (Might be irrelevant now - was last updated six months back)

This will require major restructuring for us to speed this up, which is not a safe change to make in Shiretoko's release schedule. This was blocking- for a reason.

Just some observations: I also found cutting and pasting very slow in the library and sidebar (I have 1200+ bookmarks), but this noticeably improved from 3.0 to 3.5 (not sure what changed). Also, in 3.0, while cutting-then-pasting to move existing bookmarks or folders was painfully slow, just dragging and dropping them with the mouse was almost instantaneous; I imagine they use different mechanisms.

(In reply to comment #22) In FF3.0 dragging bookmarks was acceptable only with one bookmark or one folder. As soon as several were selected and dragged, this became were slow (waiting for several seconds without ability to do anything else) to the point that dragging did not work at all anymore (no visible reaction at all to attempted drag). In fact, in FF3.0 the only workaround for me was to use Copy/Paste, albeit slow, it worked. So, I believe that it's not bound to the method, but the quantity of items to move. In the about:config I have turned off Frecency alltogether, as well as Favicons, but none of these had any noticable effect on the speed. Prelimary experimentation shows FF3.5 to be faster.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv

Are you still seeing this, after bug 472343 was fixed? You need trunk build 20101113 or newer in order to test this.

With a current nightly i can't reproduce the behavior described in the steps in comment 0 and comment 2 anymore, but the biggest improvements for both problems seem to be a lot older than bug 472343. STR comment 2: build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042506 Minefield/3.0pre hangs for some minutes, build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042606 Minefield/3.0pre for some seconds. STR comment 0: build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008070803 Minefield/3.1a1pre hangs for some seconds, build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008070903 Minefield/3.1a1pre doesn't hang.

based on comment 26 I'm marking this as WORKSFORME, since we don't have the full list of bugs involved in the final result. But I'm glad various fixes sumed up to improve the performance, thanks for your patience in retesting the behavior.