Closed
Bug 490512
Opened 16 years ago
Closed 12 years ago
Slow Bookmark Searching (with many bookmarks)
Categories
(Firefox :: Bookmarks & History, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: hakoon178, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: perf, Whiteboard: [TSnappiness])
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4
Search using the search field in the bookmark sidebar is very slow. Search results take about 15 seconds to display. Any change to the search query will have the same effect. Same test with the same number of bookmarks in Firefox 2 returns search results almost instantly (~1 second). Also, clicking on the star in the address bar and then clicking the arrow to show all the bookmarks folders takes more the one minutes to load.
Number of bookmarks: >70,000
Number of bookmark folders: >40,000
Reproducible: Always
Steps to Reproduce:
1. collect 70,000 bookmarks
2. open bookmark sidebar
3. type a search query in the search field (better to paste because if you don't type it quickly it will start searching and you have to wait before you can finish typing)
4. wait ~15 seconds for search results
Actual Results:
anxiety
Expected Results:
Instantly return search results, like Firefox 2.
Summary: Slow Bookmark Searching → Slow Bookmark Searching (with many bookmarks)
Updated•16 years ago
|
Whiteboard: [TSnappiness]
Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
This happen in Windows & Linux version, I have a Celeron D 2.93Ghz processor.
Same when display the bookmark menu, too slow with many bookmarks.
Comment 2•16 years ago
|
||
confirming for perf measurements
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•15 years ago
|
||
Is this a dupe of bug 491746? History search and bookmark search are basically the same thing, right?
Updated•15 years ago
|
Depends on: placesFolders
Comment 4•15 years ago
|
||
this could even be partly fixed right now by bug 500391. btw better having them separated, even if searching is the same, bookmarks and history are different tables and different numbers of expected results.
Depends on: 500391
Comment 5•15 years ago
|
||
An hourglass would be nice too, although I suppose bug 490714 would make that less important.
I'm getting this too, it's *quite* irritating. Takes over 30 seconds to search the bookmarks.
I should add, I have the same issue with searching the history, except worse, (the latest nightly of Firefox, as of this posting, freezes).
Comment 8•15 years ago
|
||
I have 40000 bookmarks (6000 visible). The initial versions of 3.6 fixed the slowness, but the cpu spinning was re-introduced in the past 1-2 months or so. Same bookmarks do the same thing on ubuntu and macosx, even in safe-mode.
Comment 9•15 years ago
|
||
PS. It can take 15 minutes to do a search. Over an hour to erase the search string (I give up before it finishes). Current beefy machines with 4G ram.
Comment 10•15 years ago
|
||
There is a known bug that will be fixed asap that causes searches to be 10 times slower.
Comment 11•15 years ago
|
||
which bug # do I watch for the fix?
Comment 12•15 years ago
|
||
bug 595530 is fixed on trunk (thus future FX4 beta9), what we need is a sqlite upgrade in FX3.6.x that could be Bug 598306 or bug 618315
Comment 13•13 years ago
|
||
Any news here? is this still extremely slow?
Comment 14•13 years ago
|
||
I have over 6MB bookmarks in exported HTML file and can't confirm this anymore on
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:14.0) Gecko/20120316 Firefox/14.0a1
Comment 15•12 years ago
|
||
closing until someone can actually reproduce on current version (though I still suggest filing a new bug then).
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Comment 16•12 years ago
|
||
Popping up the bookmark editor is still slow. Opened Bug 842528
You need to log in
before you can comment on or make changes to this bug.
Description
•