94576 - Filling out form with counter is slow

Status: RESOLVED FIXED

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

Description

[Ronald van Kuijk]

Results:

When you open the first attachment and start typing in the textarea below
'bericht' (marked step 5) you'll see the number reducing. This page is for
sending short messages to cell-phones and the number is the remaining number of
characters you can type for the message. The performance is real slow on my
PII-266/256MB. I can fill my keyboardbuffer completely. Try it under NS4.x or IE
to see the difference.

Attachement 2 is the same form, but the page is completely stripped of css,
tables etc. and then performance is much better, but stil not optimal.

Expected results:
Same as in NS4.x/IE

I'm running 2001080810 on Linux

I'm not sure the component is the right one. Could be events, layout, DOM

Comment 1

[Ronald van Kuijk]

Attachment: Original 'slow' page

Comment 2

[Ronald van Kuijk]

Attachment: stripped, 'normal' form

Comment 3

[Jo Hermans]

Confirmed on a 0.9.3 (base release 2001080214) on a 300 Mhz Mac. The first
example is too slow to be used. The second one is fast enough for me, no matter
how fast I type (but a Mac's event-buffer is also much larger than the PC
keyboard-buffer). But it's still a bit too sluggish. In combination with
Javascript, animating images ... that would be bad.

Comment 4

[Ronald van Kuijk]

Windows shows the same results... OS->ALL

Comment 5

[John Keiser (jkeiser)]

This does not show slow for me on Linux 2001100706.  Confirm?

Comment 6

[Asa Dotzler [:asa]]

worksforme with 100610 mozilla win32 trunk build on win2K. 

Comment 7

[John Keiser (jkeiser)]

Reopen if you continue to see this.

Comment 8

[Ronald van Kuijk]

I don't know what machine you guys are all running, but with the 2001100708
Windows build this is stil slow on my PII/233/256MB, I'll verify this later on
Linux.

Comment 9

[John Keiser (jkeiser)]

Can you be more specific about what's slow, and how slow it is on your machine?
 Like, does typing each character take 1s?  Maybe we aren't trying the right thing.

Comment 10

[Julien Cegarra]

Confirmed. (BuildID: 2001100903)

More description: entering any caracter in textbox take some time for the letter
to appear. In fact, a javascript script called "countme" count how much
caracters you entered. Removing it clean the prob for me.

Could other confirm its fixed that way ?

If thats the case, perhaps we could move that bug to "javascript engine"
component to check if any optimization is possible.

Comment 11

[kinmoz]

I'll take this from rods.

Comment 12

[Syd Logan]

Kin, performance is often pointed out to me as a critical issue, is this bug
felt to be a catchall for the issue of speed, or are we talking about just a
fringe case?

Comment 13

[kinmoz]

No this isn't a catchall for text widget performance, I just haven't had the 
time to investigate all the problems associated with the original page.

Doing a cursory look, I can see 2 things that would cause the performance to 
be terrible:

  1. The text widget is in nested tables, so typing might be causing reflows
     to leak out and reflow all the tables. There's a bug about this on
     attinasi or waterson's plate about this.

  2. There's JS handler on both the KeyUp and KeyDown that retrieves the value
     of 2 widgets, which means there are 4 invocations of the plaintext
     serializer for every character entered.

Comment 14

[Kevin McCluskey (gone)]

Moving to Mozilla1.1

Comment 15

[Ronald van Kuijk]

this bug gains an increddible amount of speed when used with the
experimental-129115 build (see bug #129115). It should probably atleast depend
on that.

Comment 16

[Ronald van Kuijk]

bug #129115 is probably (one of) the bug(s) kin meant in comment #13 point 1.

Comment 17

[Ronald van Kuijk]

Running the trunk build 2002051108, the 'slow' example page now runs normal on
my 1GHz/256MB linux laptop. I'll try my old 266MHz/256MB laptop in a moment and
close this bug if it runs normal on that system as well.

Looks like the checkin from bug 129115 fixed (at least an enormous part of) this.

Comment 18

[kinmoz]

The "Original slow page" is pretty fast, but I'm on a 1 ghz pIII. I think that
between waterson's reflow root and reflow command tree fixes, and all the perf
patches in bug 141900, this bug may actually be fixed.

Can someone test this out on a slower machine, with a trunk build that is from
06/14/02 8am or later?

Comment 19

[kinmoz]

So it looks like things are a bit faster on a Linux 500Mhz machine than they
used to be, but it still is a bit sluggish.

On a mac G3 300Mhz it both test cases are extremely fast.

I'll keep this bug open pending investigation into why it's still slow on linux.

Comment 20

[Julien Cegarra]

WFM (BuildID: 2002 08 05 08).
I think we could close that one now

/jc

Comment 21

[Ronald van Kuijk]

cannot see this anymore on my 300MHz laptop... marking fixed