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

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.

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

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.

marking m12.

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.

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.

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.

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?

Moving bug to my plate!

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

setting to M12.

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

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.

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.

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.

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

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.

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.

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

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.

Shooting for nsbeta3.

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.

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.

Removed nsbeta3 nomination from futured bugs.

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!

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

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

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?

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

catching up on verifications