2888 - Work on Linux-specific editor performance improvements

Status: VERIFIED FIXED

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

Description

[Akkana Peck]

Type-in is very slow on Linux compared to Windows.  This needs to be
investigated.

Comment 1

[leger]

Putting on performance radar.

Comment 2

[Paul MacQuiddy]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 3

[stuartp]

this seems pretty fast nowadays.. akkana?

Comment 4

[Akkana Peck]

No, it's still far slower than windows and not fast enough to keep up with a
fast typist.  sfraser did some performance analysis on the mac and determined
that the bulk of the time was being spent in reflow and in measuring text
extents; I suspect that the same is true on Linux though we don't have any
performance measurements yet to tell us that.  (Plaintext typing is quite fast,
though.)

I think there was another bug on this issue and my understanding was that the
layout group might be able to come up with some sort of font cacheing to speed
up text measurement, but I couldn't find the other bug; Simon, Kipp, any idea
what the other bug might be?

Comment 5

[Simon Fraser [no longer active]]

Bug 2254 describes slow text layout on Mac. I don't recall one specifically for
typing performance.

There are two issues here:
1. Linux and Mac are much slower than Windows. Measuring text extents may be the
   bottleneck.
2. Layout does not do incremental reflow right, on any platform.

When 2 is fixed, then we should re-visit the typing performance issue. Since
1 affects page layout in general, that should be worked on independent of its
affect on typing performance. Does that make sense?

Comment 6

[Greg Kostello]

Change Milestone to M7

Comment 7

[Akkana Peck]

Incremental reflow still causes a repaint of the entire window; can't make much
progress on performance investigations 'til that's fixed.  Adding dependency and
changing milestone.

Comment 8

[Kathleen :Brade]

akkana:  this is actually on your schedule for M10

Comment 9

[Akkana Peck]

Moving to M10 due to dependencies.

Comment 10

[Akkana Peck]

5399 was marked a dup of 1482; changing dependencies here accordingly.

Comment 11

[Kathleen :Brade]

move to M11 per akkana's schedule

Comment 12

[Akkana Peck]

Bumping off to after beta, and changing the summary -- typing is actually pretty
fast on Linux now (not to say that we don't still want more performance
improvements, of course!)

Comment 13

[leger]

Bulk add of "perf" to new keyword field.  This will replace the [PERF] we were
using in the Status Summary field.

Comment 14

[rubydoo123]

moving to m16 - load balance

Comment 15

[cbegle]

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

Comment 16

[sarnold]

I run debian frozen's m12 release, from mid-december. I currently run mozilla on
one computer, that happens to be exporting its display to another machine. There
are only the two computers, attached to each other via 100 Mbps NICs directly
connected (ie, no switch latencies, no collisions, etc..) (I can get around 3
megabytes per second between the two..)

One machine is a pentium 2, 300, with 160 megs of ram. The machine running the X
server is a k6-2 400, with 128 megs of ram. Both have plenty of free memory. The
video card in the k6-2 (running the X server) is an ATI Xpert@work -- an older
card, perhaps, but nice all the same.

I can out-type the text entry boxes, such as the one at google.com, with a bit
of concerted effort. I can out-type multiple-line text entry boxes, such as the
"additional comments" box at bugzilla with ease.

However, far more frustrating that just lagging text is the abysimal rate at
which characters are deleted with backspace and delete. It drags so slowly.

I know it is a result of mozilla, because netscape communicator 4.7 has no
problems keeping up with my typing and backspacing. (It might not backspace as
fast as I would like, but it has no trouble redrawing quickly enough to keep up
with me.) netscape communicator is being run on the same machine as mozilla,
exported to the same X server, and run under the same memory conditions. (They
are running simultaneously at the moment.)

I am running XFree86 3.3.5, 1600x1200x16bit.

Is there anything else that would help?

Thanks! :)

Comment 17

[sarnold]

I would indeed like to do profiling. I have downloaded and installed m13 (which,
BTW, looks like it handles this much nicer, but there is some goofyness with the
caret plain missing! I saw a bonzai thing with "the linux caret" in the last few
days, so I am hoping that is fixed... typing without a caret is disorienting. :)

So, I would love to do the profiling, if someone can give me a quick tutorial.

Also, if someone could add me to the cc: list, I would appreciate it -- for some
reason, I can't modify that entry in the form..[shrug]

Thanks! :)

Comment 18

[sarnold]

Hmm -- I uninstalled m13 to go back to m12. m13 was far too buggy. I would still
be happy to profile m12, or perhaps ask the debian packager guy to teach me how
to make mozilla builds for debian and grab a future snapshot.

Comment 19

[Akkana Peck]

You'll be happy to know that typing in text fields and text areas just got way
faster last week (post M13) when hyatt switched on his new XBL key handlers. 
(The old XUL key listener was a big part of the typing slowness, and XBL
replaces it.)  Hyatt is currently working on switching the editor over to XBL,
so we'll see the same speedup in the editor window; that bug is marked M14 and
we're all hoping he makes it in time.

Please don't bother profiling M12 or M13.  A lot has changed in the key handling
code since then (and also the layout reflow code, which is our other performance
problem), so it really would be a waste of time.  I would love to have help on
profiling M14 once it comes out, though, or on a daily build between now and M14
(though they haven't been very stable lately).

Comment 20

[Akkana Peck]

Sorry, didn't see sarnold's request to be put on the cc list.  Trying that now
... also removing kipp and kostello, since they're outta here.

Comment 21

[sarnold]

Well, I got the debian maintainer scripts from the debian fellow, so now I can
build .debs all day long without any trouble. :) Well, downloading the CVS tree
every day does take time, and my goodness does it take a long time to compile
the thing. :)

So, At The Moment, I am running the 02/08/00 CVS tree on my machine, and can
easily make it run whatever is newest. yay! I am trying very hard to outtype
this text entry box, but I just cannot do it. I miss my caret, that dissapeared
between m12 and m13, but the text entry does feel faster.

So, how can I profile? :) For another bug report, I am going to be rebuilding
again tonight, perhaps I can get around to profiling tomorrow. (Homework
permitting. :)

Thanks everyone. :)

Comment 22

[sarnold]

About the only comment I can make about linux performance now may also apply to
other platforms -- when loading a page with complex forms, such as most bugzilla
pages, the browser paints a grey boxes for the controls first, and then flickers
a bit before painting everything.

Is this normal/expected? Over the last few months I think I have gotten used to
quite a bit, but a friend asked me why it did that while I was playing in
bugzilla -- raising my consciousness of the event... :)

Thanks!

Comment 23

[Akkana Peck]

I've noticed that, too -- seems like it got a lot worse in the last week, too.

I'm actually going to be looking more at editor-specific performance,
particularly typing speed (since I'm on the editor team) since other people are
looking at layout and rendering performance, but of course I'm interested in
speedup anywhere we can get it.  

Comment 24

[Akkana Peck]

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

Comment 25

[Akkana Peck]

Message from above that performance isn't on the schedule for M16. :-(

Comment 26

[sarnold]

Actually, that might not be *too* bad -- typing speed under linux has improved
considerably, and most operations are fairly quick. (Of course, I run my own
squid proxy, whose cache seems to outperform the mozilla cache pretty easily.
Maybe once the disk-caching bits of the cache are turned on things will improve
similarly. :)

There are two performance issues that do need to be looked at before too
release, maybe even before beta2 -- first is the 'pre-painting' that mozilla
performs when laying out a page with html form controls. It lays out the general
shape of form controls on screen, then repositions them into place with the
drawings of the controls themselves.

Second, I am not sure memory free()ed in the program is being put back into
memory pools for use again. After running mozilla for several days, memory usage
has often grown to over 80 megs of memory. I am not sure I ever taxed the system
enough to require 80 megs of memory. Too bad Linux doesn't return memory to the
OS when it has been free()ed by a program for some length of time.

Aside from these two issues, mozilla seems right quick these days. :)

Thanks akkana et al.

Comment 27

[rubydoo123]

please do not nominate for nsbeta3 -- this will be addressed after 
crashes, regressions, correctness and polish bugs have been resolved, all 
Composer perf bugs have been set to m19/m20

Comment 28

[rubydoo123]

reviewed by Bijal and beppe, setting to p2, nsbeta3+

Comment 29

[rubydoo123]

changing to rtm, as this will be ongoing until then, re-evaluated by bij and beppe

Comment 30

[rubydoo123]

Akkana, can you give me an idea of the extent of this, the amount of coding 
effort and the degree of risk that the checkin is -- thanks

Comment 31

[rubydoo123]

removed + until i understand the level of risk and effort

Comment 32

[Akkana Peck]

Not really: this has always been a catch-all bug to cover any linux-specific
performance work that might come up.

Comment 33

[rubydoo123]

moving to future, as this is a catch-all bug

Comment 34

[rubydoo123]

updating status whiteboard with editor keyword

Comment 35

[Arthur]

Cc'ing myself.

Comment 36

[Akkana Peck]

I'm not sure why we've been keeping this bug open all this time.  It's a
catch-all but there are no known problems to catch.  It's not doing anyone any
good just sitting here.  Marking fixed.

Comment 37

[James Baxter]

Verified