Closed Bug 51939 Opened 24 years ago Closed 24 years ago

Output on large documents is very slow

Categories

(Core :: Layout, defect, P2)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: mozeditor)

References

()

Details

(Keywords: perf, Whiteboard: [see 43008][rtm need info])

Doing a copy (or autocopy on linux) on large documents is very slow, because the 
output system has to ask each piece of content if it is in the selection. This 
causes serious selection performance problems -- see bug 49772
Keywords: perf
Blocks: 49772
Adding kin@netscape.com to Cc list.
This will probably all be radically changed for the better very soon.  Cross
your fingers!
Status: NEW → ASSIGNED
m19
Target Milestone: --- → M19
Since I think this is what I saw in the profile on bug 49772, nominating for 
dogfood.  Changing to All/All, although I would think it's more serious on 
X11 than elsewhere.
Keywords: dogfood
OS: Mac System 8.5 → All
To make the dogfood-plus/minus call, we need to hear "how slow" very slow is, 
and how large the document needs to be.  This would only stop regular dogfood 
use if the email that arrives was "very large" and the slowness to reply was 
long enough that it would feel like the app had crashed (probably in excess of a 
10-30 second delay). If the size of the email was extraordinary, then it 
certainly wouldn't be common enough to stop dogfood use. Performance problems 
have to be VERY bad before they stop folks from eating the dogfood.  
Whiteboard: [NEED INFO]
if bug 43008 is fixed, then this will not be an issue, if that is not resolved, 
then this is a must fix
Priority: P3 → P2
Whiteboard: [NEED INFO] → [NEED INFO][see 43008]
this was a break out of bug 49772, if you need specific data about size, timing, 
etc, go to that bug.

However, please note that if bug 43008 is resolved, this particular bug will 
probably be resolved as well

I would prefer to see this as rtm+ and not dogfood
Keywords: rtm
Whiteboard: [NEED INFO][see 43008] → [see 43008]
Bug 43008 is not even nominated for beta3 (and hence not for Nav 5 rtm).
This does seem like a terrible bug, based on the timing in the related bug, and 
could clearly stop a person from using Nav 6 if there was any need to select 
(cut/paste).
Marking dogfood-plus.
Whiteboard: [see 43008] → [see 43008][dogfood+]
Bug 50742 will resolve this, and it's marked as rtm++.  Marking dependency.  If
that bug doesn't land, then this one will probably need to be addressed
separately.
Depends on: 50742
requesting this bug be marked as dogfood-, since this is dependent on the noxif
bug which is going in as rtm
Whiteboard: [see 43008][dogfood+] → [see 43008]
It sounds like this bug is really waiting for 50742 to resolve. Do you want to 
nominate that bug for dogfood to replace this one (which was bad enough to be a 
plus).
Beppe: You asked that this bug be downgraded. Is is better now?
Akkana, please include the required information per the rtm checkin rules
Whiteboard: [see 43008] → [see 43008][rtm+ NEED INFO]
No more to add than what has already been said.
PDT marking rtm-. Renominate if not fixed by bug 50742
Whiteboard: [see 43008][rtm+ NEED INFO] → [see 43008][rtm-]
This is not fixed by 50742, but it could be (I think) with a little more work.  
I'm working on it now.  This is a very important bug for our linux story, as 
linux selection is still dominated by our very slow copy implementation.  When 
selecting locks up the app for 30+ seconds (common on linux), we are well into 
stop ship territory...
Joe, putting back to need info, if this entails a massive amount of work,
thenlet's put this till past rtm and make it a high priority for that timeframe
Whiteboard: [see 43008][rtm-] → [see 43008][rtm need info]
Joe has a fix which greatly speeds this up: copying 2 lines in the lxr page for
nsHTMLEditor.cpp goes from 15 seconds to 5 seconds (on my 450MHz linux box), and
the output system part seems to be less than a second; the other 5 seconds are
spent somewhere else.  Joe's fix looks like it'll help a lot!
Assignee: akkana → jfrancis
Status: ASSIGNED → NEW
should land tomorrow....
Status: NEW → ASSIGNED
fixed by noxif landing
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Marking verified in the Oct 24th build.
Keywords: vtrunk
Verified again in the 2001010209 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.