Closed Bug 95461 Opened 23 years ago Closed 22 years ago

Find with WrapAround selected is very, very slow

Categories

(Core :: DOM: Editor, defect, P3)

x86
All
defect

Tracking

()

VERIFIED DUPLICATE of bug 80805
mozilla0.9.9

People

(Reporter: jesup, Assigned: akkzilla)

References

Details

(Keywords: perf)

This is from bug 31770:

This is the culprit for wrap around: 

nsFindAndReplace::GetCurrentBlockIndex()

which is basically: 
 do {
   aDoc->PrevBlock(); blockIndex++;
 } while (!at start of document);

As you can see, that's REALLY bad when you're deep in a large document.

It's accentuated a LOT by the implementation of
nsTextServicesDocument::PrevBlock, which calls the various
{Get,Find,}FirstTextNodeIn{Prev,Current,Next}Block() many times to do a
PrevBlock.

Even a trivial (and still expensive) recoding of the above to iterate forwards
from the start until it was in the same block would be vastly faster.  The best
solution would be to modify the interface to nsTextServicesDocument to support a
wrap-search more directly, so we don't have to find the current index in
nsFindAndReplace the very hard way.
Keywords: perf
Blocks: 91351
Cc sfraser.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.5
0.9.6 for now.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
This works well for me now that the fix for bug 31770 has been checked in,
searching for "hooktimer" with wrap around on the 6000-line document
lxr.mozilla.org/mozilla/source/widget/src/windows/nsWindow.cpp
This bug is most certainly still here.  The WrapAround bug gets worse the
further down the page you start.  Start 90% of the way down a 350K jprof, and it
will take 1-2 seconds on an 800MHz machine to find anything if wrap-around is
checked, while it's instantaneous without it.  At the start of the page, both
are instantaneous.

This requires some rework of either nsFindAndReplace, nsTextServicesDocument, or
quite possibly both.  The problem is that to find our current position for
Wrap-Around, it walks backwards and counts how many steps that is.  It's a very
poor interface and needs to be reworked to make it faster (like passing in a
node to stop at).
Blocks: 106961
--> Mozilla0.9.9

Trying to load-balance bug list across milestones. I will pull this bug in to a 
sooner milestone if I can.
Target Milestone: mozilla0.9.6 → mozilla0.9.9
At Kin's request, I'm looking into this; I have some code that I think will
speed it up quite a bit.
Assignee: kin → akkana
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.9 → mozilla0.9.8
See the patch I just dropped in to bug 97157.  Find with wrap should be no
slower than without wrap, and both are much faster than they were before. 
Comments or reviews solicited.
Status: NEW → ASSIGNED
The new find code went in, but preffed out.  See bug 97157 (where the patches
and commentary live) for more details.  Adding dependency, changing milestone.
Depends on: 97157
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Keywords: nsbeta1+
Keeping this bug open is just confusing since it's the same issue as in bug
80805.  Marking this as a dup of that bug.

The new faster find is in now, and can be enabled with the following pref:
user_pref("browser.new_find", true)
Please test it and report (assign to me) any bugs you see in it!  I hope to
enable it by default early next week, but that can only happen if it gets
adequately tested.

*** This bug has been marked as a duplicate of 80805 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.