414507 - With a large history, typing in the url bar lags if the typed text does not match anything

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Ed Lee :Mardak]

See discussion from bug 414489 comment 8 and forward

Comment 1

[Ed Lee :Mardak]

Attachment: v1

Comment 2

[Seth Spitzer]

Comment on attachment 299942 [details] [diff] [review]
v1

r=sspitzer, looks great to the eyeballs, but I'm trusting that you also tested it.

Comment 3

[Seth Spitzer]

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

Comment 4

[Ed Lee :Mardak]

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.

Comment 5

[Mike Connor [:mconnor]]

scary summaries ftw!

Comment 6

[Ed Lee :Mardak]

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

Comment 7

[Seth Spitzer]

> 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 8

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 299942 [details] [diff] [review]
v1

(This already landed.)

Comment 9

[Hasham]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0

Fixed in RC2. 

Comment 10

[Seth Spitzer]

> Fixed in RC2. 

I think this was fixed earlier than RC2.

Comment 11

[Hasham]

lol, marking as verified.