Closed
Bug 83205
Opened 24 years ago
Closed 12 years ago
Typing speed in autocomplete textfield is unacceptably slow and high cpu
Categories
(SeaMonkey :: Autocomplete, defect, P3)
SeaMonkey
Autocomplete
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
Future
People
(Reporter: hyatt, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: perf, Whiteboard: [nav+perf])
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.
Reporter | ||
Updated•24 years ago
|
Keywords: perf,
regression
Reporter | ||
Updated•24 years ago
|
Summary: Autocomplete unacceptably slow → Typing speed in autocomplete textfield is unacceptably slow
Reporter | ||
Comment 1•24 years ago
|
||
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).
Component: Browser-General → XP Apps: Autocomplete
QA Contact: doronr → blakeross
Comment 2•24 years ago
|
||
Plat/OS is All/All. I swear this was filed some time ago.
OS: Windows 2000 → All
Hardware: PC → All
Comment 3•24 years ago
|
||
* 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.
Status: NEW → ASSIGNED
Comment 4•24 years ago
|
||
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•24 years ago
|
||
78757 - hyatt cced. With Autocomplete turned off, there's only a slight speedup.
Updated•24 years ago
|
Whiteboard: [nav+perf]
Updated•23 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
Comment 9•23 years ago
|
||
*** Bug 104188 has been marked as a duplicate of this bug. ***
Comment 10•23 years ago
|
||
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•23 years ago
|
||
*** Bug 112205 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
clearing regression keyword, we really should use that here if autocomplete
was fast at one point, then got worse.
Keywords: regression
Comment 13•23 years ago
|
||
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.
Updated•23 years ago
|
Keywords: mozilla1.0+
Comment 16•23 years ago
|
||
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•23 years ago
|
||
*** Bug 158782 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
*** Bug 183946 has been marked as a duplicate of this bug. ***
Comment 19•21 years ago
|
||
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•21 years ago
|
||
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
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 21•20 years ago
|
||
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•17 years ago
|
||
(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
Assignee: hewitt → nobody
Blocks: 223476
Status: ASSIGNED → NEW
QA Contact: claudius
Summary: Typing speed in autocomplete textfield is unacceptably slow → Typing speed in autocomplete textfield is unacceptably slow and high cpu
Comment 23•17 years ago
|
||
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•17 years ago
|
||
not using SM mail on a daily basis, so I'm of no help there.
Comment 25•17 years ago
|
||
wrong thought. browser, not seeing problem. however, i'm using it on very speedy machine (10k rpm drives, etc)
Comment 26•16 years ago
|
||
seamonkey only, and not specific to browser history, so severing the relationship to bug 223476.
No longer blocks: 223476
Comment 27•12 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•