From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i586; en-US; m18) Gecko/20001205 BuildID: 2000120508 Large bookmark files (like the ones provided below) are extremely slugish when accessed by the pulldown menu or the Manage Bookmarks dialog box. In fact the more bookmarks you have the worse it gets until it gets unbearable Reproducible: Always Steps to Reproduce: 1. Copy Bookmark file provided below to profile directory 2. Run Mozilla 3. Try to access the bookmark file from Pulldown Menu 4. Observe how long it takes to access and move around in it Actual Results: For the first file 'bookmarks.html' which has 33 Folders and 715 bookmarks (rough 'grep -c' calculation) and is 130,806 bytes While Accessing from PullDown and Manage Bookmarks popup CPU increase: 0.1% -> 32.5% 2nd: 'bookmarks2.html' 247 Folders, 2439 bookmarks, 220,195 bytes CPU Increase: 0.1% -> 38% 3rd: 'bookmarks3.html' 583 bookmarks, NO FOLDERS, 105,143 bytes CPU Increase: 0.1% - 63% Expected Results: Able to navigate and open bookmarks with relative ease and *Much* less CPU time. Notice the fact that the more bookmarks without folders the higher the CPU usage gets, which makes sense. With any of these files the delay from the time you stop doing something until the time the computer responds gets to be several seconds at least. This can be quite annoying and is the last thing that keeps me from using Mozilla exclusively, so i would appreciate someone taking a look at it.

who would be doing bookmarks(backend) profiling and performance tuning work nowadays?

I will take this for now.. updating the title slightly just so we don't confuse this with the file reading/parsing being slow... the problem is that UI for the in-memory representation of bookmarks seems to be slow. The problem could be the in-memory datasource, or it could be inefficient styles in the bookmarks window/menus or it could be the bookmarks service.

Please don't change milestones on bugs that are not assigned to you.

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

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

adding cc

nav triage team: Not a 0.9.4 stopper, leaving at mozilla1.0 and adding perf keyword

nav triage team: Moving to mozilla0.9.5, like to get work started on this before mozilla1.0

CPU use is especially high when dragging and dropping multiple bookmarks at once in the 'Manage Bookmarks' dialog. A related problem with dragging and dropping of bookmarks is: http://bugzilla.mozilla.org/show_bug.cgi?id=89657

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

reassign to owner of bookmarks

Mass-moving lower-priority 0.9.5 bugs off to 0.9.6 to make way for remaining 0.9.4/eMojo bugs, and MachV planning, performance and feature work. If you disagree with any of these targets, please let me know.

This is a problem that can't be easily solved with the current toolkit technology. There is no concept of lazy creation of offscreen menuitems currently since the scrolled menu implementation we have is rather basic. Either a) The scrolling menu code would need to be updated to include some of the tricks used for XUL trees (lazy creation) b) an outliner used similar to the one in MozillaClassic. Both are potentially daunting tasks.

I'm shifting this post 1.0 as none of the things I've described here are likely to happen in the immediate term.

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.

Duping to the bug getting worked on *** This bug has been marked as a duplicate of 107900 ***

actually that other bug was specific to crawling into the contents of menubuttons on the personal toolbar; this bug (correct me if I'm wrong) is about scrolling/opening the top level bookmarks menu.

agreed, these are different bugs.

in build 2001-11-09-03 with a 258K file scrolling bookmarks inside folders are really fast now, but scrolling the top level folder list isn't while each sublist pops up and out.. maybe delayin the folder popup time would speed scrolling of this?

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

is bug 85851 a dup or maybe depends on this bug?

mass-reassign bookmarks & open pref perf bugs from pchen to ben

I'm seeing this only in windows. In linux there is some kind of delay when showing folder popups. Could someone add the delay to windows menus too?

Still seeing this behavior on build 2002012203 in Windows 98 SE with long list of bookmarks and getting longer.

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

Is the performance equally bad for people who have a large amount of bookmarks, but filed into folders?

No. You have to click on the folder to open it.

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

Hi. I now have the same number of bookmarks except that I don't have a long list of them that are not in any folder anymore. The bookmark section loads much faster - no complaints there, and all folders appear to be loading fast. Perhaps Mozilla needs a good bookmarks import facility which would import from Opera and ie favorites (I assume that Netscape Navigator bookmarks could be used directly. Such a facility would need to preserve folders. Another little suggestion - for debugging and benchmarking purposes, maybe there might be a visible count of the # of bookmarks and folders. Build 2002020703 Win98SE

I usually use Linux or Win98. In Linux this is not a problem but in windows98 if you quickly move your mouse over bookmarks menu, the folders will be opened without any delay. And even when the previous folder is still painting itself, the next one might get painted over it. (And I believe that is making some slowness in the bookmarks.) I tried Moz in Win2000 too and noticed that Moz's behaviour is more like in Linux (a short delay before opening the folder).

Status Report I will reference my previous note. >Hi. I now have the same number of bookmarks except that I don't have a long >list of them that are not in any folder anymore. This is not true - I have at least 500 bookmarks in the bookmark root folder. >The bookmark section loads >much faster - no complaints there, and all folders appear to be loading fast. Individual bookmarks (i.e., the whole thing) are all loading significantly faster - within reasonable usage parameters. Now my suggestion would be to provide more menu navigation support, then if necessary go back and check the speed. Build 2002022203 Win98SE

bringing dep over from dup

Steven Groginsky: Another report - I have, guessing, 200+ bookmarks in the Bookmarks ROOT directory, i.e., the lowest level, not in any folder. This is slowing me down (see build, os below). Granted they shouldn't be there, but they came there from Opera via a stupid bookmark manager program. I noticed that some work was done on bookmarks and takes care adequately of bookmarks in folders, which is as it should be. I wonder, though, if the references to folders are in the same situation as bookmarks themselves in the Root directory... Great job so far, though! Thank you! Build 2002032903 on win98se

I've got the same report as the previous commenter. In my ~250KB bookmarks.html, most of the bookmarks weren't in folders. Just today I put them all in folders. Now the bookmarks menu is not sluggish. This problem appears to be more limited than the summary indicates. Old Summary: Response rate of Bookmark Menu is very slow with large numbers of bookmarks. New Summary: large number of bookmarks not in folders makes menu respond slowly

I personally think it would be good to get this perf issue fixed by 1.0 because many people in windows who use IE do not sort their bookmarks by folders and have hundreds in their root-level folder. Just this little thing could cause the new experimenter of mozilla who is trying out 1.0 to decide this browser isn't worth his time.

I agree that this is an important bug. It should be said, though, that when IE users try Mozilla 1.0, their IE Favorites will be accessible from a Mozilla bookmarks folder, not in the root of Mozilla bookmarks. Thus, this bug won't affect them immediately. Nevertheless, it might be worthwhile to move the milestone up from where it currently is, 1.2 alpha.

In version 0.9.9 it is still slow. Will it be fixed until 1.0? It is a major bug! So priority should be set higher!

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

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

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

When there are many bookmarks in the root folder, the Bookmarks menu is slow to open. When there are many bookmarks in a folder, that folder is slow to open. It's the same problem. Changing the summary. Old Summary: large number of bookmarks not in folders makes menu respond slowly New Summary: Bookmarks menu slow with many bookmarks in root or in one folder A lot of users have observed that 4.x was better at this than we currently are.

I agree with the previous comment. I *do* remember seeing an improvement - I don't know if it was because of a patch or because I found a way of putting my root bookmarks in subfolders. I currently have a 600+ KB bookmarks file with a lot of old stuff that I'd like to sort through, and just about everything in sub-folders. I'm happy with the speed of the ones I have been accessing. I also notice that menu launcher programs have a hard time dealing with a menu of many files, like if you put Start Menu as an item. One more comment: it *is* conceivable that some smart guy will decide to set up a bookmarks tree in the personal bookmarks. I don't know if that applies to this problem - just might put it a little more in the users' face.

all my bookmarks root dir are folders. but there are some folders with no subfolders and dozen of bookmarks in them. those are the folders that takes ages (to an atom) to open. i like my bookmarks to be as messy as my mind. if i were to sort all my bookmarks, it would be as painful as sorting my desk. netscape 4.79 can open my messy folders as fast as small ones. mozilla should be able to do the same. if it doesn't in the short term, with all the 1.0 release coming around, it will gain the label of bloatware like BitchX -- it would hurt mozilla's reputation, and this is still avoidable.

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

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

Same for me, mostly. XP Pro, moz 1.0, 171kb bookmark file, about 20 folders and about 120 bookmarks unfiled. Scrolling the list is painfully disjointed. The problem seems to be in the folders and the popping up of the contents. Moving the mouse along the bookmark entries themselves is fast and proper. Same problem in NSs 6.2.

I've noticed in the last couple of days (on TRUNK builds) that Bookmarks are working a lot quicker. I'm not sure if this is purely due to my recent CPU/Mobo/RAM upgrade, or if something was fixed. Is anyone else noticing a speedup?

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

Nav triage team: nsbeta1-

happy 2 year anniversary.

I am using 2002123022/Linux, Bookmarks menu takes a few seconds to initialize (i.e. open the bookmark menu the first time after fired up mozilla). Selecting bookmark item is slow, i.e. if you move your mouse up and down on the bookmark menu, across several bookmark items, only the upper most and lower most will get selected as the mouse is moving (or waving if you prefer :)). Scrolling in the menu is even worse (definitely _NOT_ acceptable), CPU usage boost up to 75%, sucking up all CPU cycles, sometimes even after your mouse getting out of the "arrow scrolling region", the menu will scroll non-stop until it reaches the top or the bottom. which is VERY annonying. I have some Chinese and a bit Japanese on the bookmark menu, these characters may contribute to the slowness of the menu (not sure). Summary of my machine :- Intel PentiumII 350MHz 512M RAM 59K bookmark (almost all bookmarks are in root menu) Although some people suggests moving bookmark into folders solves this problem, but I do believe that it is the users' decision on how to organize the bookmark menu, and Mozilla should try its best to satisfy users' needs. I hope this bug will get fixed in 2003, finally, Happy New Year to Mozilla developers and others.

Bookmarks have been partially fixed, but are still inadequate when it comes to large bookmark lists. My bookmark list is about 6 or 7 panes in netscape currently, but it takes about 30 seconds to scroll through it with mozilla. The problem _was_ fixed, when bookmarks had a scrollable bar ... allowing you to _quickly_ scroll through them. Even better, you could use your wheel on a wheel mouse to zip through them with ease. I really feel that the current state of the bookmark list is almost as useless as _not_ having a scrollable list at all! 30 seconds is way, way too long to wait to scroll through the list, and having to move all the way to the bottom of the list, or top to do so is unacceptable. Please fix this horror. Please.

The current Target Milestone, mozilla1.2alpha, will not be met (obviously). Perhaps the Target Milestone could be changed to either: 1) --- 2) Future 3) mozilla1.x where x>3

Changing milestone based on invalidity of prior milestone. My apologies to the owner of this bug for changing something that I should not be.

The issue seems to have two parts, both adding substantially user annoyment: 1) General slowness when opening the "bookmarks" by clicking the button or menu object. If the bookmark file is large, the browser can be totally unresponsive for several seconds. 2) Slow scrolling of lists which are longer than the display height. In that particular situation user has to point the tiny arrow symbols on bottom or top to scroll (at constant speed, line at a time). Lack of a scroll bar and lack of page-at-a-time browsing makes this scrolling uncomfortably slow on longer lists/folders. One possible improvement, which is likely quite easy to implement, might be enabling keyboard PageUp/PageDown buttons for page-at-a-time browsing of the list. These two problems have a major impact on users' perception of usability, and should be prioritized. IMHO the new Target Milestone|mozilla1.2alpha must not slip!

Sooru about my referance to 1.2alpha, which, as pointed out by shill@free.fr, is already an old release. I SHOULD have stated is that it must not slip further. Mea culpa. This bug was originally reported in December 2000, and once it was tageted to be fixed to 1.2 alpha. It is still around at least in 1.3b. IE 6.0 has a similar scroll-button arrangement, but Mozilla could (and should!) do it better. However, when comparing IE6 and Mozilla with identical bookmarks/favorites list (I exported one from Mozilla to IE), IE6 is considerably shorter time unresponsive when opening the whole list. I assume the current code is simply more inefficient in Mozilla--see the original CPU usage figures. Please define the new target to be in not-too-far future.

FWIW, Mozilla 1.4 takes 12 seconds to bring up the bookmark display after I hit the bookmark button or type cntrl-B. However it's OK after that.

Problem persists in 1.4 release exactly as described lately. In my case, I imported a 1.6MB bookmarks from NS-4.78 that I am still using it.

Top oprofile results from Firebird 2003-08-01 CVS build on Linux, measuring only the bookmark menu open after a firebird start. Small bookmarks file of 165K, approximate menu open time is 3 seconds or so. CPU: PIII, speed 863.205 MHz (estimated) Counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit mask of 0x00 (No unit mask) count 20000 vma samples % image name symbol name 00383a00 3458 2.1052 libgklayout.so SelectorMatches(RuleProcessorData&, nsCSSSelector*, int, nsIAtom*, signed char) 00057410 3432 2.0894 libxpcom.so SearchTable 000da660 2082 1.2675 libxpcom.so nsCOMPtr_base::~nsCOMPtr_base() 000576f0 1864 1.1348 libxpcom.so PL_DHashTableOperate 00000000 1824 1.1105 libX11.so.6.2 (no symbols) 000782fe 1592 0.9692 libgklayout.so __i686.get_pc_thunk.bx 004347d0 1564 0.9522 libgklayout.so nsXULElement::QueryInterface(nsID const&, void**) 420745e0 1529 0.9309 libc-2.3.2.so _int_malloc 004399f0 1491 0.9077 libgklayout.so nsXULElement::GetAttr(int, nsIAtom*, nsIAtom**, nsAString&) const 00234e40 1398 0.8511 libgklayout.so nsRuleNode::GetStyleData(nsStyleStructID, nsStyleContext*, int) 42073ce0 1330 0.8097 libc-2.3.2.so __malloc 00056f1b 1189 0.7239 libxpcom.so __i686.get_pc_thunk.bx 0037c840 1167 0.7105 libgklayout.so RuleHash::EnumerateAllRules(int, nsIAtom*, nsIAtom*, nsVoidArray const&, void (*)(nsICSSStyleRule*, nsCSSSelector*, void*), void*) 000da730 993 0.6045 libxpcom.so nsCOMPtr_base::begin_assignment() 002456d0 977 0.5948 libgklayout.so nsStyleContext::GetStyleData(nsStyleStructID) 0002bd20 942 0.5735 libnspr4.so _PR_x86_AtomicIncrement 000c7310 861 0.5242 libxpcom.so AppendUTF8toUTF16(nsACString const&, nsAString&) 00014600 843 0.5132 libnspr4.so PR_AtomicIncrement 0043ff90 839 0.5108 libgklayout.so nsXULElement::FindLocalAttribute(nsINodeInfo*) const 0043c890 835 0.5083 libgklayout.so nsXULElement::GetID(nsIAtom**) const

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

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

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

As of the middle of 2004, I'm using a recent Mozilla release (1.7) on Linux, and this problem remains really horrible. If I click on the "Bookmarks" in the menu bar, Mozilla hangs for a full 15 seconds before the menu pad opens. This is really annoying because "Bookmarks/Bookmark this group of tabs..." is a great feature, but there's no other way of getting at it (no keyboard shortcut). My bookmarks.html file has a little over 1500 bookmarks in the root folder (it's total size is about a megabyte). I'm using: Mozilla 1.7 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 I suggest that if the performance issues aren't easily solveable, the solution would be to not display any bookmarks in the Bookmarks menu pad. There are already at least two other ways of getting at them: the Bookmark Manager window and the Bookmark pane of the sidebar.

When there are more bookmarks than will fit in a column, I would prefer that that they display in a multicolumn fashion instead of seeing "scroll arrows" at the top and/or bottom of a single column. I feel that this should be configurable. Multiple columns should be displayed, similar to setting StartMenuScrollPrograms to "NO" in HKLM\Software\Microsoft\Windows\CurrentVersion\explorer and HKLM\Software\Microsoft\Windows\CurrentVersion\explorer\Advanced in the Windows Registry.

As for having more columns than will fit on the screen, add a "Left Arrow" scroll control to the left side of the multicolumn display, and a "Right Arrow" control to the right side, to scroll one *column* at a time instead of one *bookmark* at a time.

I see this bug on the newer trunk builds in the Bookmarks menu and in Bookmarks Toolbar folders; the rest of the menus are normal speed. The way you can best see it is that it visibly draws the shadow underneath, and then draws the menu. At first I thought it was because the shadow code was memory or processor intensive, but I disabled the shadow effect in Windows, but the menu STILL has the delay. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060320 Firefox/1.6a1 ID:2006032009

This is really annoying. It seems only the "Bookmarks" bookmarks menu has this problem though. The sidebar loads as fast as usual, but Firefox freezes for 10 seconds on 2 GHZ machine which is...ugh

I just noticed that this bug is for "Mozilla Application Suite" yet I am using Firefox 2.0 and have this issue. I'd say it's common to both products. Perhaps with the Firefox Places rewrite it will go away though.

*wanted to say that perhaps the product should be "core" instead, or there should be two separate bugs for the Firefox and Seamonkey bookmark bugs.

Just downloaded version 3.0.5 for Mac and the slow response of the Bookmarks pull-down menu is still v. slow when you have a large Bookmarks list as I do [1500 and counting, accumulated over 10 years]. This wasn't the case with version 1.5 which I had been making do with until now, since I found version 2 had this slow response problem. The keyboard shortcuts to Add or Manage Bookmarks do however respond instantantly, so I now use those. The Bookmarks sidebar also responds pretty much instantly. I was nenver quite sure why the pull-down menu appeared to list all bookmarks; they seem to be in a random order, and not searchable, so not particularly useful. Perhaps the pull-down menu would respond quicker and therefore be more useful for adding and managing bookmarks if the list of bookmarks were omitted. Perhaps the Bookmarks sidebar command could be under the Bookmarks pull-down menu instead. Similarly the History sidebar

Just finished testing, imported all three attached files getting >700 items in main bookmark menu, no any speed issues here. CPU: 5 years old Athlon X2 5200+ Is somebody still able to reproduce this issue?

Yes, this is still an annoying issue. Using only 700 items under root is not a meaningful test, try with at least 7000 - 10000 items and think that there are people that have bookmarked much more URIs (20000 - 30000) with a lot of "pain" in usability terms :-) Last stable version of Seamonkey with 7000 entries / items in bookmarks requires almost "11 seconds" to show up the first time bookmarks menu is opened and "1-2 seconds" in subsequent times; Windows XP dual core 2.5 GHz I agree with proposals in comment 73, so, beyond trying to optimize code further, here are a few ideas with some hints that could help to solve the issue. 1) Try to load bookmarks in memory by a secondary thread soon after browser has been started; usually user does not access bookmarks menu the first time he/she wants to navigate to a site because "bookmarks toolbar" or navigation history toolbar are preferred for frequently accessed sites. 2) As now bookmarks are stored in a DB, what about trying to load them on demand ? Load and show only those that fit in current menu window panel plus a few more and load the others when they are required by a scroll event. Most people are happy with the current functionality that let see bookmarks in the same order they were bookmarked or where they were manually moved (into groups, etc.), because this gives them a very good spatial control on where bookmarks can be found, so there should not be big problems with implementation due to sort issues, etc. 3) What about splitting the bookmarks menu in 2 sections ? The first one should show all commands and fast access bookmarks (those in toolbar, most recently bookmarked, etc.) whereas the second one should show all the remaining bookmarks only on demand, i.e. by clicking on a triangular button aside a label "Other bookmarks ...", etc. Maybe this solution could be combined with solution 1) or 2) for the part regarding the load of all "other bookmarks".

(In reply to A.D.F. from comment #75) > Using only 700 items under root is not a meaningful test, try with at least > 7000 - 10000 items and think that there are people that have bookmarked much > more URIs (20000 - 30000) with a lot of "pain" in usability terms :-) It's looks like insanity for me, can you provide real-world example of file (no matter places or exported to bookmarks.html) with such amount of bookmarks?

(In reply to Phoenix from comment #76) > (In reply to A.D.F. from comment #75) > > Using only 700 items under root is not a meaningful test, try with at least > > 7000 - 10000 items and think that there are people that have bookmarked much > > more URIs (20000 - 30000) with a lot of "pain" in usability terms :-) > > It's looks like insanity for me, can you provide real-world example of file > (no matter places or exported to bookmarks.html) with such amount of > bookmarks? Of course no because of privacy :-) and because you know you can easily create a custom bookmarks.html by some shell script and then you can import it for testing purposes. Anyway it's not insanity, it's real life, so be assured that 5000 - 10000 items is quite common for people who are surfing the web for at least 6-8 years and this bug is 12 years old ! Size of a "small" 7000 items bookmarks: bookmarks.html 2.6 MB places.sqlite: 40.5 MB No tags, no keywords nor descriptions were added to item URIs, so if you want add them to test their "load" and also explore the program usability with 20000 - 30000 items then it would be certainly a good thing considering that human beings expect a program reaction (after a command) within 1/10 of second (limit of good responsiveness) or at most 1 second (before thinking at the damn program / machine as deadly slow).