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

Putting on performance radar.

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

this seems pretty fast nowadays.. akkana?

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?

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?

Change Milestone to M7

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.

akkana: this is actually on your schedule for M10

Moving to M10 due to dependencies.

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

move to M11 per akkana's schedule

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!)

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

moving to m16 - load balance

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

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! :)

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! :)

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.

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).

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.

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. :)

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!

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.

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

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

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.

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

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

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

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

removed + until i understand the level of risk and effort

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

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

updating status whiteboard with editor keyword

Cc'ing myself.

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.

Verified