83205 - Typing speed in autocomplete textfield is unacceptably slow and high cpu

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Autocomplete, defect, P3)

Description

[David Hyatt]

The autocomplete widget is very slow, even on my 700mhz with an optimized 
build.  I suspect that the autocomplete widget is not using a timer when it 
should.  When a character is pressed, you should use setTimeout and not worry 
about any completion or putting up of popups until the timer has blown.

Even a tiny tiny timer delay (50ms?) would probably dramatically improve 
performance.

Comment 1

[David Hyatt]

Other ideas would be to make sure you are reusing the outliner and popup and 
not destroying and recreating them on every keypress (which I believe may be 
happening as well).

Comment 2

[James Green]

Plat/OS is All/All. I swear this was filed some time ago.

Comment 3

[Joe Hewitt (gone)]

* autocomplete is in fact on a timer - and your guess of 50ms was correct.
* Unless something regressed, the outliner frame is definitely not recreated on
each keystroke.  It is only recreated each time the popup is opened.

When you say that the widget is slow, are you refering to the time it takes to
open the popup when you start typing, or do you find it to be slow even as you
continue to type?   I suspect the slowness is only in opening the popup because
several paint commands may be issued before the popup is displayed.

Comment 4

[James Green]

Typing speed is slow. I'm sure I've mentioned this in another bug. I'll try and
find it.

FWIW, I have Autocomplete turned off, and there is no speedup at all, it's still
unacceptably slow.

Comment 5

[James Green]

78757 - hyatt cced. With Autocomplete turned off, there's only a slight speedup.

Comment 6

[rbs]

Adding dependency on bug 75511 which may share a part of the blame.

Comment 7

[Chris Hiner]

*** Bug 88591 has been marked as a duplicate of this bug. ***

Comment 8

[Jarrod Gray]

*** Bug 91358 has been marked as a duplicate of this bug. ***

Comment 9

[Jesse Ruderman]

*** Bug 104188 has been marked as a duplicate of this bug. ***

Comment 10

[Tomas Ögren]

I just fired up the solaris 8 build of 0.9.5 on one of our 170 MHz Sparcstation
5's and with all autocompletion turned off it couldn't keep up with my typing.
Should it take about 50 million cpu cycles to process one keypress? Doesn't feel
right :/

Comment 11

[Matthias Versen [:Matti]]

*** Bug 112205 has been marked as a duplicate of this bug. ***

Comment 12

[Chris McAfee]

clearing regression keyword, we really should use that here if autocomplete
was fast at one point, then got worse.

Comment 13

[[e-mail]]

Is this a conseqence of trapping onkeypress? I say this because I find that the
JS console evaluator textbox is also fairly slow, it has an onkeypress handler.

Comment 14

[Blake Ross]

changing qa to claudius.

Comment 15

[Peter Trudelle]

nsbeta1- per Nav triage team

Comment 16

[Chris B. Sears]

I have the same typing speed problem with forms.

This is noticeable with Yahoo mail when replying to a message.  It is inserting
into the front of a long string.  IE with the same page, a Yahoo reply, never
falls behind on typing.

I think this is related but I could be wrong.

This could be related to:

  Bug 110325 - Typing is slow in espn.com text widgets
  Bug 119318 - typing slows down in text areas as you enter text
  Bug 128658 - Typing in textarea really slow
  Bug 119487 - Typing in table with background transparent gif is slow.

This is on a 266MHz Power Macintosh G3.  Of course, slowness is more noticeable
on a slow machine/

Comment 17

[WD]

*** Bug 158782 has been marked as a duplicate of this bug. ***

Comment 18

[Andrew Hagen]

*** Bug 183946 has been marked as a duplicate of this bug. ***

Comment 19

[Matthew Elvey]

I suggest a new pref: 
browser.urlbar.autocomplete.minimumLength

If I type a "t" in the urlbar, Mozilla is frozen for 10 seconds (==
HISTORY_SYNC_TIMEOUT seconds, perhaps?).

I think this is because I have lots of urls starting with t. 

Pseudocode for a fix (for someone else to use as a starting point; I don't
normally code in C++):

Insert something like this at
http://lxr.mozilla.org/seamonkey/source/xpfe/components/history/src/nsGlobalHistory.cpp#4063
:

// If the search string is short, then 
// there is no need to proceed with the search.

PRInt32 minLen
gPrefBranch->GetIntPref(PREF_AUTOCOMPLETE_MINIMUM_LENGTH, &minLen);

if (length(searchString < minLen) {
     listener->OnAutoComplete(?????);
     return NS_OK;
   }

http://lxr.mozilla.org/seamonkey/source/xpfe/components/history/src/nsGlobalHistory.cpp#110,
add: 
#define PREF_AUTOCOMPLETE_MINIMUM_LENGTH              
"urlbar.autocomplete.minimumLength"

http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#165 : add
pref("browser.urlbar.autocomplete.minimumLength", true);

Comment 20

[will smith]

I find this worst when I start up Mozilla.  I have history set to 365 days of
history.  Then when I first start and type a URL, it gets stuck after about 3
letters, freezes, then comes back.

I'd guess it only instantiates some big objects the first time you type in the
URL bar, and this instantiation grows the more history items there are.

Will Smith

Comment 21

[Alan Batie]

This sounds similar to what I'm seeing on 733Mhz G4 OSX: when entering addresses
in composing mail, I'll type an address, hit enter and start typing the next
address.  When I don't pause after hitting Enter, the Enter is delayed, and it
puts part of the second address after the first address, then continues the rest
of  the second address in the second address field.

Comment 22

[Wayne Mery (:wsmwk)]

(In reply to comment #19)
> If I type a "t" in the urlbar, Mozilla is frozen for 10 seconds ...
> I think this is because I have lots of urls starting with t. 

I see this even with a small history file (2.5MB, 18 days).
Lots of matches to first one and two characters that has many URLs in history.
Another symptom is a few (or many more) seconds of high cpu.

Solving this would help bug 223476, but places takes over before that can happen. However, places is not immune to this general problem - see bug 373256

Comment 23

[Tony Mechelynck [:tonymec]]

No comment since 7 months. In the meantime I've seen a lot of work being done on the Fx3 Autocomplete interface, which, however, is not yet shared by SeaMonkey: one item was avoiding that typing h should freeze the browser by trying to retrieve all "http" and "https" URLs.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050101 SeaMonkey/2.0a1pre
I'm not seeing this problem. Wayne (or anyone), do you still see it on current Sm-trunk nightlies? If you do, I suppose fixing this bug should wait for the porting of places.sqlite (and what goes with it) to SeaMonkey? Is there already a bug number for that porting? Or if you don't know, who would?

Comment 24

[Wayne Mery (:wsmwk)]

not using SM mail on a daily basis, so I'm of no help there.

Comment 25

[Wayne Mery (:wsmwk)]

wrong thought. browser, not seeing problem. however, i'm using it on very speedy machine (10k rpm drives, etc)

Comment 26

[Dietrich Ayala (:dietrich)]

seamonkey only, and not specific to browser history, so severing the relationship to bug 223476.

Comment 27

[Philip Chee]

There are two issues conflated here which confuses things:
1. Slow typing in urlbar - which may be affected by history size.
2. Slow typing in other autocomplete boxes.

I'm going to close this as INCOMPLETE. For any current issues please file a NEW bug as our codebase is likely to be radically different from what it was in 2001.