Output on large documents is very slow




19 years ago
18 years ago


(Reporter: sfraser_bugs, Assigned: mozeditor)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


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



19 years ago
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


19 years ago
Keywords: perf


19 years ago
Blocks: 49772

Comment 1

19 years ago
Adding kin@netscape.com to Cc list.

Comment 2

19 years ago
This will probably all be radically changed for the better very soon.  Cross
your fingers!

Comment 3

19 years ago
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

Comment 5

19 years ago
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]

Comment 6

19 years ago
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


19 years ago
Whiteboard: [NEED INFO] → [NEED INFO][see 43008]

Comment 7

19 years ago
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]

Comment 8

19 years ago
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 
Marking dogfood-plus.
Whiteboard: [see 43008] → [see 43008][dogfood+]

Comment 9

19 years ago
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
Depends on: 50742

Comment 10

19 years ago
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]

Comment 11

19 years ago
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 
Beppe: You asked that this bug be downgraded. Is is better now?

Comment 12

19 years ago
Akkana, please include the required information per the rtm checkin rules
Whiteboard: [see 43008] → [see 43008][rtm+ NEED INFO]

Comment 13

19 years ago
No more to add than what has already been said.

Comment 14

19 years ago
PDT marking rtm-. Renominate if not fixed by bug 50742
Whiteboard: [see 43008][rtm+ NEED INFO] → [see 43008][rtm-]

Comment 15

19 years ago
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...

Comment 16

19 years ago
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]

Comment 17

19 years ago
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

Comment 18

19 years ago
should land tomorrow....

Comment 19

19 years ago
fixed by noxif landing
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 20

19 years ago
Marking verified in the Oct 24th build.


19 years ago
Keywords: vtrunk

Comment 21

18 years ago
Verified again in the 2001010209 build.
You need to log in before you can comment on or make changes to this bug.