12541 - Rich text copy is 5 times slower than IE

Status: VERIFIED FIXED

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

Description

[Eli Goldberg]

* 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).

Comment 1

[Mike Pinkerton (not reading bugmail)]

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.

Comment 2

[Eli Goldberg]

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.

Comment 3

[Eli Goldberg]

[QA Assigning to self.]

Comment 4

[Eli Goldberg]

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.)

Comment 5

[Mike Pinkerton (not reading bugmail)]

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.

Comment 6

[Mike Pinkerton (not reading bugmail)]

marking m12.

Comment 7

[Mike Pinkerton (not reading bugmail)]

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.

Comment 8

[Mike Pinkerton (not reading bugmail)]

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.

Comment 9

[Mike Pinkerton (not reading bugmail)]

actually removing depenedency

Comment 10

[Mike Pinkerton (not reading bugmail)]

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.

Comment 11

[Mike Pinkerton (not reading bugmail)]

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?

Comment 12

[harishd]

Moving bug to my plate!

Comment 13

[Eli Goldberg]

[haven't checked performance on today's build due to disabling of all Copy/Paste
menu items. Will check tomorrow.]

Comment 14

[harishd]

setting to M12.

Comment 15

[Eli Goldberg]

[Marking as dependent upon 14026, as I can't provide any additional information
unless 14026 is fixed.]

Comment 16

[Akkana Peck]

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).

Comment 17

[rickg]

Moving to m14.

Comment 18

[Eli Goldberg]

...held off until copy (mostly) was functional within the browser. Still blocked
by either 21832 and possibly 21847; will check again with M13...

Comment 19

[Mike Pinkerton (not reading bugmail)]

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.

Comment 20

[harishd]

test..ignore this

Comment 21

[harishd]

test...ignore this comment

Comment 22

[Eli Goldberg]

[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. ;-]

Comment 23

[Akkana Peck]

I reopened 14026 yesterday on copy/paste not working in the browser window.

Comment 24

[leger]

Moving "perf" to keyword field.  This is the are we use now :-)

Comment 25

[Eli Goldberg]

Resolving as WORKSFORME so that it goes onto my radar screen for checking --- if 
copy/paste actually works yet.

Comment 26

[Eli Goldberg]

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.

Comment 27

[Eli Goldberg]

[Lowering severity from 'Critical' to 'Major', on grounds that performance 
improved by a factor of four since bug was written.]

Comment 28

[harishd]

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.

Comment 29

[harishd]

Since this is not  a PDT+ bug moving to M15.

Comment 30

[Eli Goldberg]

Using the 3.5.00 AM build, the copy required 3 seconds. (Sorry for the follow-up 
delay --- non-PDT issue, so low priority.)

Comment 31

[Mike Pinkerton (not reading bugmail)]

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....

Comment 32

[harishd]

Moving to M16.

Comment 33

[harishd]

Eli, is this still slow?  Please update me. Thanx

Comment 34

[harishd]

M17..

Comment 35

[Eli Goldberg]

Using the 5.2.00 AM build, this operation took four seconds.

Comment 36

[harishd]

Apparently, this is happening only on very slow machines.  But would be nice to 
be fixed for rtm.  Adding rtm to the keywords.

Comment 37

[harishd]

Shooting for nsbeta3.

Comment 38

[Eli Goldberg]

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.

Comment 39

[Nisheeth Ranjan]

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.

Comment 40

[Nisheeth Ranjan]

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. 

Comment 41

[Nisheeth Ranjan]

Removed nsbeta3 nomination from futured bugs.

Comment 42

[Mike Pinkerton (not reading bugmail)]

with the xif exorcism, is this still the case?

Comment 43

[Hixie (not reading bugmail)]

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!

Comment 44

[John Morrison]

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].

Comment 45

[John Morrison]

> 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

Comment 46

[John Morrison]

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

Comment 47

[Hixie (not reading bugmail)]

John: Cool, thanks! Is this now a Mac-specific bug then?

Comment 48

[John Morrison]

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).

Comment 49

[harishd]

This is not a parser problem anymore since XIFDTD has been yanked. This bug 
should probably belong to Johnny. 

Comment 50

[Johnny Stenback (:jst)]

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?

Comment 51

[Kathleen :Brade]

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

Comment 52

[anthonyd]

this is working grreat for me.  there have been a lot of improvements in this 
and it is practically instantaneous for me.

anthonyd

Comment 53

[rubydoo123]

catching up on verifications