Closed Bug 12541 Opened 20 years ago Closed 18 years ago

Rich text copy is 5 times slower than IE

Categories

(Core :: HTML: Parser, defect, P3)

defect

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: elig, Assigned: anthonyd)

References

()

Details

(Keywords: perf)

* TITLE/SUMMARY
[Perf] [PP] Rich text copy is 20 times slower than Navigator/IE

* STEPS TO REPRODUCE
0) Launch Apprunner
1) View http://slip/projects/marvin/copy-paste/copy-large-text/shortpage.html. (a
200K web page)
2) Select its contents, and choose Copy from the Edit menu.

* RESULT
 - What happened

On a 266 Mhz G3, this operation takes 5 seconds. On our minimum Mac configuration
(100 Mhz 601), this operation would have required nearly 30 seconds.

* Mac IE 4.5 performs the rich text copy task instantaneously. (e.g. .5 seconds)
* Navigator 4.7 performs the copy (plain text) instantaneously, as well.

*** On Windows using a 233 Mhz P2, there's something seriously wrong. Apprunner
freezes up during the paste into WordPad and doesn't consistently work. I'll look
into it in greater detail, and write up a bug report if applicable. ***

 - What was expected

Speed of of large pages should be roughly on par with other browsers.

* REGRESSION

 - Occurs On
        Mac OS Apprunner (1999082412)

 - Doesn't Occur On
        Win32 Apprunner (8.24.99 AM optimized build [NT 4, Service Pack 3])

 - didn't check Linux --- it only shows garbage when scrolling large pages
downwards, rendering accurate selection impossible.


* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).
Status: NEW → ASSIGNED
i'm confused. you say that win32 freezes, but it is only a mac problem? and you
say it takes 5 seconds to copy, which is too long, but IE does it
"instantaneously (eg 5 seconds)".

Now i'm sure this is valid, but i'm just confused about the details.
QA Contact: beppe → elig
Oh, sorry, Mac IE 4.5 required .5 (aka 0.5) seconds.

Win32 is inconsistent in how it behaves. I'll investigate it further and insert
something coherent here ASAP.
[QA Assigning to self.]
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Summary: [Perf] [PP] Rich text copy is 20 times slower than Navigator/IE → [Perf] Rich text copy is 20 times slower than Navigator/IE
User error; I eat my words.

It's cross-platform. You probably knew that already.

(In short, unlike Mac OS, Apprunner on Windows gave no feedback as to when the
copy operation had finished, beyond ignoring UI events during the copy.)
i'm curious about builds since i changed the d&d/clipboard impl's to use more COM
machinery so we can access from JS. That went in for daily builds Wed and on. If
nothing, i'm sure it got even worse since i have another bug (for my own
reference) that we copy the data waaaaay too much.
Blocks: 12671
marking m12.
Target Milestone: M12
Whiteboard: 1 day once dependency is fixed.
Assignee: pinkerton → akkana
Status: ASSIGNED → NEW
Component: XPApps → Parser
This is not actually the clipboard's fault. I've profiled the code with the above
url and 95% of the time is spent converting xif->html or xif->text (0.79 of 0.83
seconds for html and 0.80 of 0.84 seconds for text). Note that we do the html
conversion twice because the aol mail flavor is html with a tag on the beginning
and a tag on the end.

This is all in the parser/stream code. Even though we're copying the data a few
too many times, it is vastly overshadowed by the parser. Resetting the component
and reassigning to akk.
Status: NEW → ASSIGNED
Assignee: akkana → rickg
Status: ASSIGNED → NEW
removing dependency, as profiling shows it's not.

i profiled the stream code on xif->text and it's spending most of the time in the
parser. The text conversion of 200K of text takes 0.79 seconds and only the last
0.17 is spent in the text stream code. Everything else is parser.

As a result, reassigning to rickg.
No longer depends on: 12278
actually removing depenedency
i just nsAutoString'd and CBufDescriptor'd the text stream code and cut that time
in half. It's now .09 of .76 seconds. Still the parser is the bottleneck.
Severity: normal → critical
Whiteboard: 1 day once dependency is fixed.
Target Milestone: M12
clearing milestone and whiteboard. marking critical (being a perf problem).

i started profiling the parser and it looks like the bulk of the time is spent in
nsParser::Tokenize() doing:

    while(NS_SUCCEEDED(result)) {
      mParserContext->mScanner->Mark();
      ++mMinorIteration;
      result=theTokenizer->ConsumeToken(*mParserContext->mScanner);
     ....
  }

There are literally hundreds of small calls to consumeToken and Mark. Doesn't
look like any silver bullet here, just many many calls to the same routine in a
tight loop. This might be a good place to start, but i'm totally unfamiliar with
the tokenizer or the scanner.

rick? can you help out here?
Assignee: rickg → harishd
Moving bug to my plate!
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M11
[haven't checked performance on today's build due to disabling of all Copy/Paste
menu items. Will check tomorrow.]
Target Milestone: M11 → M12
setting to M12.
Depends on: 14026
[Marking as dependent upon 14026, as I can't provide any additional information
unless 14026 is fixed.]
If anyone's looking for a way to test this, cut/copy/paste still work in the
editor windows, even if they don't in the browser ... at least on Linux (and I
haven't seen a bug on them on other platforms).
Depends on: 16285
Target Milestone: M13 → M14
Moving to m14.
...held off until copy (mostly) was functional within the browser. Still blocked
by either 21832 and possibly 21847; will check again with M13...
21847 isn't a dependency for this bug. sure, we are over eager about placing the
data on the clipboard before it is needed, but the sheer act of placing it there
is still quite slow. at some point, we need to export all the flavors, usually at
app shutdown. it's all where we pay the price.
test..ignore this
test...ignore this comment
[using the 2000010409 Mac OS build, the copy doesn't work at all; menu item
flickers as if a normal copy, contents of clipboard are unchanged. Not sure if
that's 9670, but will re-open it and find out. ;-]
I reopened 14026 yesterday on copy/paste not working in the browser window.
Keywords: perf
Summary: [Perf] Rich text copy is 20 times slower than Navigator/IE → Rich text copy is 20 times slower than Navigator/IE
Moving "perf" to keyword field.  This is the are we use now :-)
Resolving as WORKSFORME so that it goes onto my radar screen for checking --- if 
copy/paste actually works yet.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Using the 2.7.00 AM Mac OS build on a 266 Mhz G3, it now takes 2.75 seconds to 
copy the context.

Communicator 4.7 performed this task instantaneously (plaintext copy); IE took .5 
seconds (rich text copy).

Thus, re-opening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: Rich text copy is 20 times slower than Navigator/IE → Rich text copy is 5 times slower than IE
[Lowering severity from 'Critical' to 'Major', on grounds that performance 
improved by a factor of four since bug was written.]
Severity: critical → major
Status: REOPENED → ASSIGNED
Priority: P1 → P3
Eli, lots of performace work, in the parser, went in the last couple of days.
(02/10, and 02/11). Could you please verify this bug.  Thanx.
Since this is not  a PDT+ bug moving to M15.
Target Milestone: M14 → M15
Using the 3.5.00 AM build, the copy required 3 seconds. (Sorry for the follow-up 
delay --- non-PDT issue, so low priority.)
changing the url, to give a better test case. god, this is really really bad. 
we're talking _many minutes_ here.

http://slip/projects/marvin/copy-paste/copy-large-text/longtablepage.html

according to bug 21847, we eventually run out of memory. not sure who's problem 
that is....
Moving to M16.
Target Milestone: M15 → M16
Eli, is this still slow?  Please update me. Thanx
M17..
Target Milestone: M16 → M17
Using the 5.2.00 AM build, this operation took four seconds.
Apparently, this is happening only on very slow machines.  But would be nice to 
be fixed for rtm.  Adding rtm to the keywords.
Keywords: rtm
Shooting for nsbeta3.
Keywords: rtmnsbeta3
Target Milestone: M17 → M18
The machine used for testing was similar in performance to a Rev C iMac, which is 
in very common use (and I think still even sold). 

I'm not sure what defines a 'very slow' machine, but this nonetheless remains an 
issue for 'very popular' machines.
I just tried this on windows and the cut and paste of 
http://slip/projects/marvin/copy-paste/copy-large-text/shortpage.html took 1-2 
seconds.  That seems to be an acceptable amount of time for now.  We can 
potentially optimize this post rtm.  Marking future.
Target Milestone: M18 → Future
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 
Keywords: nsbeta3
Removed nsbeta3 nomination from futured bugs.
QA Contact: elig → janc
with the xif exorcism, is this still the case?
Nominating for nsbeta1 for Netscape triage team to ascertain importance with
respect to the embedding requirements.

Reassigning QA to jrgm, since this is more a performance/UI thing than a parser
thing from a QA point of view. John, Could you have a look at this and see if it
is still a problem? Cheers!
Keywords: mozilla0.9, nsbeta1
QA Contact: janc → jrgm
I created a bit less intensive version of that buglist, that had 5
<TABLE>s, with a total of 3000 rows of content (1.1MB) (reduced since
IE5 on win2k went buh-bye* on the original page).

Here are the numbers I get:

          Nav4.7       mozilla          IE5.x
------------------------------------------------
win2k       5s           2.5s            9s
mac         7s            9s            ~2s 
linux 
  select    4s            3s             -
  copy      4s            5s             -


* buh-bye == > 90 seconds

Times on linux and win2k are cpu seconds, mac is wall clock.
Linux measure both the selection and the "concrete" copy, since
they both fill clipboards (but selection times on mac and win2k
are ~2s for all browsers anyways).

Okay, so we apparently are the winners on win2k, split decision on
linux, and we could use some improvement on mac, especially relative
to IE. 

For the original page, on a Mac 500MHz G4, I can't discern a time for 
the copy to complete (and I don't have a tool to check CPU, not being 
a mac weenie and all).

But whatever this is, it's no longer a critical performance issue.
"Normal" sized document/copies execute in acceptable times on
mac/linux/win2k.

[p.s., that's not to say that there aren't some other performance issues
in dealing with that big tables page, which I'll attach, but just that 
the copy operation doesn't seem to be a big issue now].
> For the original page, on ...

For the original page that elig was noting this bug on :
   http://slip/projects/marvin/copy-paste/copy-large-text/shortpage.html
I can't discern a time for the copy to complete.

(pinkerton later changed the URL to the mondo page:
   http://slip/projects/marvin/copy-paste/copy-large-text/longtablepage.html


I see that bugzilla choked on my attachment. It's here internally:
  http://jrgm/bugs/12541/tables-page-3000-rows.html
and its just simply a bugzilla bug list, with 5 tables, 3000 TR total, 1.1 MB
John: Cool, thanks! Is this now a Mac-specific bug then?
The biggest difference is on the mac, although I don't know if this is in 
XP code or platform code -- but I can only measure an effect on a 500MHz/256MB
G4 when dealing with a very large ~1MB HTML document. (Whatever the 
classification, this is very much in the Future category, IMHO).
Severity: major → normal
This is not a parser problem anymore since XIFDTD has been yanked. This bug 
should probably belong to Johnny. 
Assignee: harishd → jst
Status: ASSIGNED → NEW
Reassigning to anthonyd who I believe is the new proud owner of the serializer
code. The performance neck could now be in either the serializers or in the
document encoder but I have no idea why this is so slow on the mac compared to
other os'es. Anthony, jfrancis might be able to help with the mac performance
problems here since he knows the document encoder code very well (and he has
macs to play with). Could someone point a mac profiler on this code, or use the
debugger to see what we're doing here?
Assignee: jst → anthonyd
I'm not sure if I'm testing exactly the right things.  Also, I'm testing in a
debug build so that may also play a (significant?) factor.  I think there is
room for improvement based on these:
Mac Debug build in Browser window using
http://slip/projects/marvin/copy-paste/copy-large-text/longtablepage.html
  Select All took about 10 seconds
  Copy       took about 23 seconds

Windows Debug build in Browser window using same url as Mac
  Select All took about 13 seconds
  Copy       took about 20 seconds
this is working grreat for me.  there have been a lot of improvements in this 
and it is practically instantaneous for me.

anthonyd
Status: NEW → RESOLVED
Closed: 20 years ago18 years ago
Resolution: --- → FIXED
catching up on verifications
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.