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

Categories

(Firefox :: Address Bar, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 3 beta3

People

(Reporter: Mardak, Assigned: Mardak)

References

Details

(Keywords: perf)

Attachments

(1 file)

See discussion from bug 414489 comment 8 and forward
Depends on: 414489
Attached patch v1Splinter Review
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.
Attachment #299942 - Flags: review?(seth)
Attachment #299942 - Flags: review+
Attachment #299942 - Flags: approval1.9?
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".
Flags: blocking-firefox3?
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
Keywords: perf
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?
Depends on: 414581
Comment on attachment 299942 [details] [diff] [review]
v1

(This already landed.)
Attachment #299942 - Flags: approval1.9?
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.