Closed
Bug 2888
Opened 26 years ago
Closed 23 years ago
Work on Linux-specific editor performance improvements
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: akkzilla, Assigned: akkzilla)
References
Details
(Keywords: helpwanted, perf, platform-parity, Whiteboard: [perf])
Type-in is very slow on Linux compared to Windows. This needs to be
investigated.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Summary: [PP] performance: Linux typing is very slow → [PP]: Linux typing is very slow
Whiteboard: [Perf]
Comment 2•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Updated•26 years ago
|
Target Milestone: M4
Assignee | ||
Comment 4•26 years ago
|
||
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•26 years ago
|
||
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?
Updated•26 years ago
|
Target Milestone: M4 → M7
Comment 6•26 years ago
|
||
Change Milestone to M7
Assignee | ||
Comment 7•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M10 → M8
Comment 8•25 years ago
|
||
akkana: this is actually on your schedule for M10
Assignee | ||
Updated•25 years ago
|
Target Milestone: M8 → M10
Assignee | ||
Comment 9•25 years ago
|
||
Moving to M10 due to dependencies.
Assignee | ||
Comment 10•25 years ago
|
||
5399 was marked a dup of 1482; changing dependencies here accordingly.
Updated•25 years ago
|
Target Milestone: M10 → M11
Comment 11•25 years ago
|
||
move to M11 per akkana's schedule
Assignee | ||
Updated•25 years ago
|
Target Milestone: M11 → M12
Assignee | ||
Updated•25 years ago
|
Summary: [PP]: Linux typing is very slow → [PP]: Work on Linux-specific performance improvements
Target Milestone: M12 → M15
Assignee | ||
Comment 12•25 years ago
|
||
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•25 years ago
|
||
Bulk add of "perf" to new keyword field. This will replace the [PERF] we were
using in the Status Summary field.
Updated•25 years ago
|
Target Milestone: M15 → M16
Comment 14•25 years ago
|
||
moving to m16 - load balance
Comment 15•25 years ago
|
||
*** Bug 24799 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Summary: [PP]: Work on Linux-specific performance improvements → Work on Linux-specific performance improvements
Whiteboard: [Perf]
Comment 16•25 years ago
|
||
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•25 years ago
|
||
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•25 years ago
|
||
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.
Assignee | ||
Comment 19•25 years ago
|
||
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).
Assignee | ||
Comment 20•25 years ago
|
||
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•25 years ago
|
||
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•25 years ago
|
||
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!
Assignee | ||
Comment 23•25 years ago
|
||
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.
Summary: Work on Linux-specific performance improvements → Work on Linux-specific editor performance improvements
Assignee | ||
Comment 24•25 years ago
|
||
*** Bug 26383 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 25•25 years ago
|
||
Message from above that performance isn't on the schedule for M16. :-(
Target Milestone: M16 → M17
Comment 26•25 years ago
|
||
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.
Assignee | ||
Updated•24 years ago
|
Target Milestone: M17 → M19
Comment 27•24 years ago
|
||
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•24 years ago
|
||
reviewed by Bijal and beppe, setting to p2, nsbeta3+
Whiteboard: [nsbeta3+][p:2]
Updated•24 years ago
|
Priority: P2 → P1
Whiteboard: [nsbeta3+][p:2] → [rtm+][p:1]
Comment 29•24 years ago
|
||
changing to rtm, as this will be ongoing until then, re-evaluated by bij and beppe
Comment 30•24 years ago
|
||
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
Whiteboard: [rtm+][p:1] → [rtm+][p:1]awaiting eval
Comment 31•24 years ago
|
||
removed + until i understand the level of risk and effort
Whiteboard: [rtm+][p:1]awaiting eval → [rtm][p:1]awaiting eval
Assignee | ||
Comment 32•24 years ago
|
||
Not really: this has always been a catch-all bug to cover any linux-specific
performance work that might come up.
Comment 33•24 years ago
|
||
moving to future, as this is a catch-all bug
Comment 34•23 years ago
|
||
updating status whiteboard with editor keyword
Priority: P1 → P3
Whiteboard: [p:1] → [perf]
Comment 35•23 years ago
|
||
Cc'ing myself.
Assignee | ||
Comment 36•23 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•