Closed Bug 414507 Opened 13 years ago Closed 13 years ago
With a large history, typing in the url bar lags if the typed text does not match anything
See discussion from bug 414489 comment 8 and forward
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #299942 - Flags: review?(seth)
Comment on attachment 299942 [details] [diff] [review] v1 r=sspitzer, looks great to the eyeballs, but I'm trusting that you also tested it.
playing with the bugzilla fields here, I hope that's cool. if this were my bug, I would also change the subject to something scary like: "with a large history, typing in the url bar lags if the typed text does not match anything".
Priority: -- → P1
Target Milestone: --- → Firefox 3 M11
Yup. Unit tests pass and it's back to pre-global frecency where results slowly come in. I'm actually thinking we might want to up the chunk size even more. SELECT COUNT(*) FROM moz_places WHERE frecency > 100 2157 pages with frecency above 100 SELECT COUNT(*) FROM moz_places 12231 pages Remember that *right now* we're searching through *all places* in less than a second. At least with the user tunable pref, we can get more feedback on this.
scary summaries ftw!
Flags: blocking-firefox3? → blocking-firefox3+
Checking in toolkit/components/places/src/nsNavHistory.h; /cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.h,v <-- nsNavHistory.h new revision: 1.126; previous revision: 1.125 done Checking in toolkit/components/places/src/nsNavHistoryAutoComplete.cpp; /cvsroot/mozilla/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp,v <-- nsNavHistoryAutoComplete.cpp new revision: 1.36; previous revision: 1.35 done
Summary: Search by chunks meaning pages to check per timeout, not pages to add per timeout → With a large history, typing in the url bar lags if the typed text does not match anything
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
> Yup. Unit tests pass go go dietrich unit tests! > and it's back to pre-global frecency where results slowly come in. That should not be true when the search term results in lots of hits (like http), right? > I'm actually thinking we might want to up the chunk size even more. I think you might be right. I hate to throw this into the mix, but let's make a spin off bug about this: from faaborg's quoted research we know that x ms is the max time we can not respond before people notice lag. I can't remember his number off the top of my head, but lets say it was 100 ms. we can add timing code into the product that changes the chunk size dynamically. haven't fully thought this out, but say on machine X we determine that AutoCompleteFullHistorySearch() with chunk size of 100 takes me 10 ms. Clearly chunk size on that fast machine can be more. but on machine y, chunk size of 100 takes me 250 ms. that would be bad times, and we need to do less. I'm suggesting we add the timing code (we have something with good enough precision, PR_Interval something right?), and keep track of the high water mark of how long AutoCompleteFullHistorySearch() takes a member variable. then, the next time we call nsNavHistory::StartSearch(), if high water mark is > 100 ms, we decrease the pref for chunk size. if high mater mark < 100 ms, we increase it. alternatively, there might be a way (through PR_SysInfo something else?) to figure out the RAM / CPU of the machine, and "guess" a better chunk size. ok, I'll put away the crazy stick now. what do you guys think?
Comment on attachment 299942 [details] [diff] [review] v1 (This already landed.)
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0 Fixed in RC2.
> Fixed in RC2. I think this was fixed earlier than RC2.
lol, marking as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.