49468 - nsTextInputListener::Focus() is slow

Status: RESOLVED WORKSFORME

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

Description

[Simon Fraser [no longer active]]

nsTextInputListener::Focus() is called whenever a text widget is focussed (e.g. 
when you bring the browser window to the front with focus in the url bar). It 
accounts for about 60% of the time taken to handle the focus event, which seems 
high. The slow part is the call to nsGfxTextControlFrame::GetText(), which goes 
through the output system.

This same code path happens when you type in a textfield (only with maxlength) 
because we measure the length of the text each time. We should optimize this.

Comment 1

[Simon Fraser [no longer active]]

(only with maxlength) should be been a query (only with maxlength?) since I'm not 
sure if we only do this if the field has a maxlength specified on it. We should.

Comment 2

[Akkana Peck]

Didn't we at one time (pre ender lite, so maybe it's not there in ender lite
text controls) have an optimization where the text control remembered its
current text, so it didn't have to go through the output system unless something
happened that might change the text?  Or is that impossible because we're
worried that someone might change the content out from under the text control?

There's a lot of room for optimization in the output system (and there are bugs
filed on that, but they're nsbeta3-, of course) but as long as it has to go
through XIF, it will be somewhat slow even if the rest of the process is
optimized (going through XIF involves two parsing stages and a lot of memory
allocation/copying).  It would be much better if we could cache.

Comment 3

[Simon Fraser [no longer active]]

nsTextInputListener::Focus() is getting the value of the text field and storing 
it, so that it can compare with the value on Blur(), and thus know to fire an 
onChange event.

Almost all the time in GetText() is spend in nsDOMSelection::ToString()

Comment 4

[Simon Fraser [no longer active]]

A lot of time is being spent in nsRange code here too. nsRange is the class that 
takes the most time (exclusive of children) in this whole operation; it does a 
lot of mallocs via creating new ranges, and manipulating nsVoidArrays.

Comment 5

[Joe Francis]

there has been an addition to the dom spec for range (at my request, my god i've 
affected a w3c spec - when will the madness end!) that will allow us to recycle 
ranges.  So we may be able to aviod the mallocs by maintaining a pool of ranges.

The voidarray stuff is more problematic: it's part if the implementation.  I 
already cahce voidarrays statically in range so that i dont have to alloc them 
all the time.  I don't know of any more quick wins there but that doesn't mean 
there aren't any.

You should introduce me to your call chain data and I can think about ways to 
speed things up.

Comment 6

[Charles Manske]

Simon: Is this still a problem? Are you covering it in other performance bugs?

Comment 7

[Simon Fraser [no longer active]]

This needs to stay open for Range perf improvements.

Comment 8

[Simon Fraser [no longer active]]

Mozilla0.9

Comment 9

[rubydoo123]

adding nsbeta1 for 6.5

Comment 10

[Simon Fraser [no longer active]]

Won't get to this for 0.9

Comment 11

[Simon Fraser [no longer active]]

-> 0.9.2

Comment 12

[Simon Fraser [no longer active]]

-> mozilla 1.0

Comment 13

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 14

[Simon Fraser [no longer active]]

Pre-sabbatical bug triage.

Comment 15

[Simon Fraser [no longer active]]

Pre-sabbatical bug triage.

Comment 16

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 17

[Simon Paquet [:sipaq]]

This bug hasen't been touched for years and is clearly unowned. Moving back to default assignee/QA so that people, who are watching those can accurately triage this bug.

Also resetting Priority, Target Milestone, Status Whiteboard and Status.

Comment 18

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

There is no such method and we've already optimized a lot around getting text editor value for Quantum Flow. Let's close this ancient bug, and feel free to file new bug if you still see some slow methods at moving focus.