62907 - Bookmarks menu slow with many bookmarks in root or in one folder

Status: NEW

(SeaMonkey :: Bookmarks & History, defect, P2)

Description

[Keyser Sose]

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.

Comment 1

[Claudius Gayle]

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

Comment 2

[Alec Flett]

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.

Comment 3

[Keyser Sose]

Attachment: Bookmark File #1

Comment 4

[Keyser Sose]

Attachment: Bookmark File #2

Comment 5

[Keyser Sose]

Attachment: Bookmark File #3

Comment 6

[Alec Flett]

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

Comment 7

[Keyser Sose]

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

Comment 8

[timeless]

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

Comment 9

[Ben Guthrie]

adding cc

Comment 10

[Paul Chen]

nav triage team:

Not a 0.9.4 stopper, leaving at mozilla1.0 and adding perf keyword

Comment 11

[Paul Chen]

nav triage team:

Moving to mozilla0.9.5, like to get work started on this before mozilla1.0

Comment 12

[Ari]

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

Comment 13

[Keyser Sose]

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

Comment 14

[Alec Flett]

reassign to owner of bookmarks

Comment 15

[Peter Trudelle]

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.

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 17

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 19

[Keyser Sose]

Duping to the bug getting worked on


*** This bug has been marked as a duplicate of 107900 ***

Comment 20

[John Morrison]

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.

Comment 21

[Claudius Gayle]

agreed, these are different bugs.

Comment 22

[[not reading bugmail]]

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?

Comment 23

[Chris Lyon]

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

Comment 24

[basic]

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

Comment 25

[Peter Trudelle]

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

Comment 26

[Olli Pettay [:smaug][[e-mail]]]

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? 

Comment 27

[Steven Neil Groginsky]

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

Comment 28

[André Dahlqvist]

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

Comment 29

[André Dahlqvist]

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

Comment 30

[Steven Neil Groginsky]

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

Comment 31

[Chris Lyon]

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

Comment 32

[Steven Neil Groginsky]

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

Comment 33

[Olli Pettay [:smaug][[e-mail]]]

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).

Comment 34

[Steven Neil Groginsky]

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

Comment 35

[basic]

bringing dep over from dup

Comment 36

[Steven Neil Groginsky]

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

Comment 37

[Andrew Hagen]

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

Comment 38

[Brandon Ryan]

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.

Comment 39

[Andrew Hagen]

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.

Comment 40

[Gerhard Wiesinger]

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!

Comment 41

[Boris Zbarsky [:bzbarsky]]

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

Comment 42

[Andrew Hagen]

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

Comment 43

[Andrew Hagen]

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

Comment 44

[Andrew Hagen]

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.

Comment 45

[Steven Neil Groginsky]

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.

Comment 46

[la hache]

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.

Comment 47

[Andrew Hagen]

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

Comment 48

[Andrew Hagen]

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

Comment 49

[jeff givens]

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.

Comment 50

[David G King]

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?

Comment 51

[Chris Lyon]

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

Comment 52

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 53

[Yvo van Doorn]

happy 2 year anniversary.

Comment 54

[Chu Alan "sprite"]

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.

Comment 55

[Brad Barnett]

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.

Comment 56

[Mason]

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

Comment 57

[David G King]

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

Comment 58

[Teuvo Telaranta]

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! 

Comment 59

[Teuvo Telaranta]

Sooru about my referance to 1.2alpha, which, as pointed out by [e-mail], 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.

Comment 60

[samlew_lksk]

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.

Comment 61

[hamdix]

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.

Comment 62

[John Levon]

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

Comment 63

[Andrew Hagen]

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

Comment 64

[Andrew Hagen]

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

Comment 65

[Asa Dotzler [:asa]]

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

Comment 66

[Joseph "What is reality?" Brenner]

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. 

Comment 67

[James B. Higgs]

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.

Comment 68

[James B. Higgs]

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.

Comment 69

[mmortal03]

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

Comment 70

[disgruntled.toaster]

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

Comment 71

[disgruntled.toaster]

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.

Comment 72

[disgruntled.toaster]

*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.

Comment 73

[ROBIN PETHERBRIDGE]

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

Comment 74

[Phoenix]

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?

Comment 75

[A.D.F.]

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".

Comment 76

[Phoenix]

(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?

Comment 77

[A.D.F.]

(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).