Closed Bug 13687 Opened 25 years ago Closed 25 years ago

nsHTMLEditor::OutputToString called many times on startup

Categories

(Core :: XUL, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: buster)

Details

Attachments

(1 file)

On startup, nsHTMLEditor::OutputToString is called 12 (more or less) times.
(Bruce noticed this because a small leak in the XIF converter showed very
prominently in Purify logs.)  This seems like a performance hit, since all of
these have to go through the parser twice (and there are some known performance
problems in the parsing process).

Most of these calls are coming via
nsGfxTextControlFrame::InternalContentChanged, presumably from the URL bar
(since that's the only text field actually showing in the default browser
window).
Target Milestone: M12
simple performance work set to M12
Status: NEW → ASSIGNED
Whiteboard: [Perf]
Putting on [Perf] radar.
This function also gets called every time the mouse enters (or moves over?) any
part of the browser window (not just over the text field itself).
Severity: normal → major
Priority: P3 → P2
I'll jump on this early in M12. I can do some smart caching, I'm sure.
Severity: major → normal
Priority: P2 → P3
Whiteboard: [Perf] → [help wanted] now that I have most of the fix in, I could use some real purify data on this
mostly fixed.  still needs some data, but I think I got rid of most of the
noise.  Reducing the priority and severity since it's mostly if not completely
fixed.
beppe asked suresh to help with doing a purify run on this to confirm.  buster,
akkana, can we just bring up the Editor under Tasks in 5.0 and close the window?
Then, we'd take the Win32 Purify log resulting from that and attach to this bug
report for you to review.  Thanks.
Lisa: the editor window won't show this, because it doesn't have any text fields
in it.  Try the browser window (url bar) and the mail compose window (addressing
field).

I'm still seeing this function called every time I enter the mail compose window
(I haven't tested the browser window/url bar recently).  It's only called once
per enter event, though, not multiple times.
We'll do this with M12 tip builds:
1.  Start Seamonkey into the browser window.
2.  Place the mouse into the URL field and go to bugzilla.mozilla.org
3.  Exit Seamonkey
-->Capture log 1

1.  Start Seamonkey into Mail
2.  Compose a new message - html compose window
3.  Place the cursor into the addressing field and enter some text
4.  Close the compose window
5.  Exit Seamonkey
--> Capture log
Don't forget to move the mouse in and out of the window (the whole window, not
just the text field) several times, since that calls the function again.

Note that the original bug wasn't on a leak, it was on a performance problem
(the fact that text fields call the parser too often).  I certainly don't want
to discourage anyone from running purify since that's always a worthwhile thing
to do, but quantify data might be more on target for addressing whether this is
still a performance problem.
Ok. Beth told me Purify.  If Suresh has Quantify set up, he can do this also.
I will run purify and attach 2 logs as per Lisa's comments at 14:52.
I will also post a Quantify data ASAP. Thanks.
I have posted 2 Purify logs at http://jazz/users/suresh/publish/bug13687/.
Both the logs are as per Lisa's comment on 11/12/99 14:52 plus moving mouse in
and out of the whole window.
I will try to post the Quantify data ASAP. (I have some license key issues with
Quantify Software. :-(   )
Target Milestone: M12 → M13
still waiting for quantify data....
moved to M13.
Sorry about the delay. Rational Software never replied back to me. Will call
them again today.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: [help wanted] now that I have most of the fix in, I could use some real purify data on this
I believe this is now fixed.
The way to test this is to run quantify and see how frequently
nsHTMLEditor::OutputToString is called.  You will need a a couple of test cases:
one that has just a text control, one that has just a text area, and one that
has a large number of both (maybe 20 of each.)  Run viewer under quantify for
each, and you should see a very small number of calls to
nsHTMLEditor::OutputToString.  Resize the windows, do mouse overs, etc.  The
counts shouldn't go very high.  If you have any questions about whether you're
getting a reasonable number of counts, contact me and we'll discuss it.
QA Contact: claudius → suresh
Suresh, can you look at this?
QA Contact: suresh → stephend
QA Contact: stephend → stephen.donner
QA Contact: stephen.donner → stephend
This seems fixed to me.  I tried Buster's testcase and I'll attach a 
screenshot, sorted by function call of the Quantify output gathered running 
under Windows 2000 with a current trunk build of viewer.exe.
Verified fixed (If I'm going about this wrong, let me know).
Status: RESOLVED → VERIFIED
Thanks Stephend!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: