Closed Bug 368240 Opened 18 years ago Closed 18 years ago

A link on the bottom of the history list takes long to load

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3 alpha5

People

(Reporter: ria.klaassen, Assigned: moco)

References

Details

Attachments

(1 file, 3 obsolete files)

Steps to reproduce: - Start Firefox with a large history - Load history sidebar - Set View - By Last Visited - Scroll down and click on the last entry Result: link takes 5 seconds to select and to load. - Then put your mouse on the scrollbar slider and scroll up Result: it takes 3 seconds before the slider follows your movement. I see this since Bug 366589 was fixed because before that time there was no long term history "By Last Visited" in the sidebar.
This is still happening.
Blocks: 380307, 381326
Component: History → Places
QA Contact: history → places
ok, thanks to the venkman profiler (thank you rginda), here's what going on. First, PU_getIndexOfNode() was resulting to a lot of calls to asContainer: asContainer: 64-65, 189624 call(s), 2640.63ms total, 0ms min, 15.63ms max, 0.01ms avg, excluding calls: 625ms total, 0ms min, 15.63ms max, 0ms avg Looking at PU_getIndexOfNode, we were calling asContainer(parent) in our loop, so I was able to move that side the loop. That was a noticable saving per call to PU_getIndexOfNode() for items at the bottom of the history list (sorted by last visited). Then I looked at why were we calling PU_getIndexOfNode() so many times, and the reason is command updating. For certain commands (like cmd_paste, but there are others), we call PC__canInsert(), which calls tree's insertionPoint(), and if there is an insertion point, we can insert. but insertionPoint() is not cheap, so calling it for command updating can really slow things down. As an optimization, I have fixed PC__canInsert() to check if the container is readonly, and if so, we can't insert. This speeds up history and other tree uses, such as when doing a search over bookmarks (in the sidebar or bm dialog). here comes a patch
Assignee: nobody → sspitzer
Status: NEW → ASSIGNED
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → Firefox 3 alpha5
Attached patch patch (obsolete) (deleted) — Splinter Review
Attachment #265616 - Flags: review?(mano)
Comment on attachment 265616 [details] [diff] [review] patch I suspect that comment is cut. I would rather make this part of the insertion point getter though, if possible.
Attachment #265616 - Flags: review?(mano) → review-
Attached patch updated patch (obsolete) (deleted) — Splinter Review
Attachment #265616 - Attachment is obsolete: true
Attachment #265677 - Flags: review?(mano)
Attached patch complete fix (obsolete) (deleted) — Splinter Review
forgot the utils.js part of the patch
Attachment #265677 - Attachment is obsolete: true
Attachment #265678 - Flags: review?(mano)
Attachment #265677 - Flags: review?(mano)
Comment on attachment 265678 [details] [diff] [review] complete fix >Index: browser/components/places/content/utils.js >=================================================================== >RCS file: /cvsroot/mozilla/browser/components/places/content/utils.js,v >retrieving revision 1.38 >diff -u -8 -p -r1.38 utils.js >--- browser/components/places/content/utils.js 17 May 2007 01:14:27 -0000 1.38 >+++ browser/components/places/content/utils.js 22 May 2007 16:34:59 -0000 >@@ -417,17 +417,18 @@ var PlacesUtils = { > NS_ASSERT(aNode, "null node"); > > var parent = aNode.parent; > if (!parent || !PlacesUtils.nodeIsContainer(parent)) > return -1; > var wasOpen = parent.containerOpen; > parent.containerOpen = true; > var cc = parent.childCount; >- for (var i = 0; i < cc && asContainer(parent).getChild(i) != aNode; ++i); >+ var parentContainer = asContainer(parent); >+ for (var i = 0; i < cc && parentContainer.getChild(i) != aNode; ++i); make that asContainer(parent); for (var i = 0; i < cc && parent.getChild(i) != aNode; ++i); r=mano otherwise.
Attachment #265678 - Flags: review?(mano) → review+
Attached patch as checked in (deleted) — Splinter Review
Attachment #265678 - Attachment is obsolete: true
Attachment #265700 - Flags: review+
fixed. Checking in browser/components/places/content/utils.js; /cvsroot/mozilla/browser/components/places/content/utils.js,v <-- utils.js new revision: 1.40; previous revision: 1.39 done Checking in browser/components//places/content/tree.xml; /cvsroot/mozilla/browser/components/places/content/tree.xml,v <-- tree.xml new revision: 1.69; previous revision: 1.68 done as always, thanks to Ria for the great bug report!
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Verified in Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/200708020808 Minefield/3.0a7pre. I don't see this in the current builds.
Status: RESOLVED → VERIFIED
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: