52005 - [FIXr]poor performance scrolling large plain text files (scrolling is slow)

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[janne hayrynen]

scrolling the plain text file in the above url is painfully slow, on a 600mhz
machine i get about 2 updates per second.

Comment 1

[janne hayrynen]

tested with build 2000090808..

Comment 2

[Eugene Savitsky]

WFM on win2000

Comment 3

[Decklin Foster]

I can hardly get this page to render on my linux system, much less scroll.
This doesn't seem to be any of the existing scroll/perf bugs so confirming and
adding perf keyword.

Comment 4

[Doron Rosenberg (IBM)]

How about loading this page from harddisk? Is it still slow? If no, could be
netwerking issue. If yes, I have no idea where this goes (editor?)

on win98, there is a small noticable degrade in speed

Comment 5

[janne hayrynen]

loading this file from harddisk it takes 2.5 minutes to render with 100% load on
a k7/600 and scrolling is just as slow as before.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

-> Layout.  A profile would help...

Comment 7

[Kevin McCluskey (gone)]

Dividing up Claytons bugs to triage

Comment 8

[rods (gone)]

This document is certainly an edge case. Nav 4.x loads faster and scrolls 
faster. Rick assigning this to you because you may have a better feel where we 
should start. Or maybe this is a dup of an obviously known bug.

Comment 9

[rickg]

Rods: I'm sending this back to you. I don't have the cycles to track it down. 
Please try to find another owner.

Comment 10

[rods (gone)]

next release

Comment 11

[janne hayrynen]

hmm. a few things i noticed:
even just moving mouse over the window with this file loaded causes 100% cpu
load, and selecting is also dead slow.

Comment 12

[Tomi Leppikangas]

I load that url in viewer with profiling on (eazel-profile), you
can see results at:

http://www.student.oulu.fi/~tomilepp/mozilla/2000-10-29.html

Profiling adds some overhead, so dont look so much on seconds, call counts
should be real numbers thought. I only profiled initial layout, not scrolling.

Comment 13

[selmer (gone)]

3/12 04 WinNT

Scrolling is plenty fast on NT.  Loading this page though, brought my entire app
to a standstill.  None of my windows would respond while this was loading initially.

Comment 14

[janne hayrynen]

with linux build 2001031205 scrolling the URLs plain text file is still
agonizingly slow, less than 2 updates/second on a 600mhz machine, which might be
even slower than it used to be when i first reported this.

loading the page is veeery slow too, as you described.

there are also few other issues with large plain text files that should probably
be reported separately:

-one such thing is the enormous amount of GetFrameForPoint() calls launched on
mouse movement that causes cpu usage to jump to 100% on even smallest mouse
moves. it's really _enormous_ if you compare it with GetFrameForPoint() calls
launched when mousing over normal html files.

-cpu usage on expose/repaint.

Comment 15

[Benjamin Mucci]

Same thing under MacOS. Very Slow. For fun just download a log file from a Web
Server...  the scrolling is "agonizingly slow". 

Comment 16

[Oliver Klee]

Bug 60371 may be related.

Comment 17

[Jure Repinc (JLP)]

ftp://ftp.funet.fi/pub/doc/dictionaries/Finnish/words.finnish

Very slow on my mashine (AMD Athlon 1333 MHz, 512 PC133 CAS2 RAM). Using Mozilla
2002020208 on Windows XP.

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

http://non-us.debian.org/debian-non-US/pool/non-US/main/m/mozilla/mozilla_0.9.9-1.diff.gz
is another, very slow, example.

changing summary for easier searching

Comment 19

[lohphat]

Status update: This page is still slow on 2002050504 win32 on win2kpro.

What's more interesting is that all Moz pages are slow while this page is
loading.  I have it in another tab and trying to update this bug and this page
is slow in scrolling as well.

Comment 20

[Rainer Bielefeld]

WFM with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020531   and RC3

Please have a look on bug 100951 !

Can we close this bug ?  keywords --> qawanted ?

Comment 21

[janne hayrynen]

still slow with rc3 on linux. i now have 1.4ghz athlonxp and i get about 3
updates per second scrolling this file.

other things to note, while not necessarily related to scrolling, rendering this
file from disk takes 15 seconds and redrawing when the window comes on top takes
about 3 seconds.

Comment 22

[josh]

I get the same thing on my Tosh Sat Pro 6100. Changing the Keyboard section of
the XF86Config file has no discernable effect.

Comment 23

[David G King]

Re Comment 17, works fine for me with WinXP and build 2002-09-27.

Can someone retest with a new build on a Linux machine.

Comment 24

[Jure Repinc (JLP)]

Reply to comment 23.
I still have the same problem here. The scrolling gets slower and slower while
the file is downloading. And when it finishes the whole file (make sure you wait
to the end) it is extremely slow. I'm currently using build 2002092808.

Comment 25

[janne hayrynen]

Linux 2002092905

No improvements since last time i checked. This time about 25 seconds to load
and 3-4 updates per second when scrolling. Redrawing when window comes on top
takes ~2 seconds.

Comment 26

[Eric Hopper]

This is not a plain text file, but it is very simple HTML.

http://www.tuxedo.org/~esr/jargon/jargon.html

Both selection and scrolling are very slow (comparitively) for this page.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Comment 27

[Boris Zbarsky [:bzbarsky]]

Attachment: Profile of scrolling this page

Comment 28

[Boris Zbarsky [:bzbarsky]]

So the problem seems to be that the two main culprits
(nsBlockFrame::PaintChildren and nsBlockFrame::PaintFloaters) both have to walk
the entire line list to paint.  Which means, in this case, that every repaint on
a one-line scroll has to walk this huge line list and check, for every line,
whether that line intersects the dirty rect (for PaintChildren) and whether that
line contains floaters (for PaintFloaters).

We could maybe keep the "has any floaters at all" information in the block frame
itself... but I'm not sure what we can do about the "line intersects dirty rect"
stuff.

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Most blocks obey the invariant that the sequence of "line->combinedArea.y"s is
non-decreasing and the sequence of "line->combinedArea.YMost()"s is also
non-decreasing. So how about this: keep a bit in the block that is set only if
the invariant holds. We can clear the bit at the beginning of reflow and set it
during any "pass over all lines" that we do (e.g., during painting). Also keep
in the block a reference to a line, let's call it the cursor. When we paint, if
the invariant bit is set then we can search for the first line whose
line->combinedArea.YMost > damageRect.y and start painting from there. We can
also stop when line->combinedArea.y >= damageRect.YMost. The search for the
first line can start from the cursor and go either forward or back; we reset the
cursor to the new first line.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Ooh.  That sounds promising, yes... ;)

Comment 31

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This should be fixed by my patch in bug 51938, which addresses painting as well
as event handling.

*** This bug has been marked as a duplicate of 51938 ***

Comment 32

[Boris Zbarsky [:bzbarsky]]

roc, that patch still leaves the O(N) walk in PaintFloats().  With the patch
applied, scrolling the URL in the URL field of this bug spends 57% of time in
PaintFloats() (and only 3% in PaintChildren()).

I really wonder whether we can store a flag that says that none of the lines
have floats... it could be used to optimize more than just PaintFloats.

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is there any particular reason why PaintFloats needs to crawl the lines, instead
of just iterating through the block frame's child floater frame list? Is it
something to do with paint ordering?

Comment 34

[Boris Zbarsky [:bzbarsky]]

Floats are _really_ not my forte... ;)  David, do you know the answer to comment 33?

Comment 35

[Boris Zbarsky [:bzbarsky]]

OK, ordering can't possibly be an issue here.  nsBlockFrame::BuildFloatList()
(called after every reflow) ensures the invariant that mFloats is linked in
exactly the same order that traversing the lines gives.

Of course BuildFloatList has all these XXX comments about it being a perf
problem  and needing to go, but I presume that whatever we replace it with will
maintain the same invariant?

Comment 36

[Boris Zbarsky [:bzbarsky]]

Attachment: So this should be safe

Comment 37

[Boris Zbarsky [:bzbarsky]]

Attachment: Same as diff -w

Comment 38

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 143892 [details] [diff] [review]
Same as diff -w

With this patch, testing on that Finnish dictionary in the URL bar, I see
the following changes of behavior:

1)  Holding down the arrow key or pgup/pgdown key only uses about 40% of CPU,
    not 100% on my machine.
2)  Scrolling is smooth, not choppy.
3)  Releasing the arrow key makes scrolling stop immediately, not seconds
later.
4)  A realtime profile shows almost all the time spent in __libc_poll.
5)  A non-realtime profile shows that the function most time is spent in
    (2.7% of total) is nsDOMEvent::QueryInterface (called from
    nsXBLWindowHandler::WalkHandlersInternal, mostly).

This may even be safe enough to land in beta, given what I said about the
BuildFloatList() invariant above...  If you think it's not, please say so.

Comment 39

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 143892 [details] [diff] [review]
Same as diff -w

Could we take this for 1.7b?  This makes scrolling on very long pages much much
more pleasant...

Comment 40

[chris hofmann]

Comment on attachment 143892 [details] [diff] [review]
Same as diff -w

trying shut down to get beta out tomorrow morning.  let's try and get a few
people to pound on this and maybe take for 1.7 final if its agreed that the
risk is small and nothing turns up.

Comment 41

[Boris Zbarsky [:bzbarsky]]

OK, sounds reasonable.  Anything I can do to facilitate said pounding?

Comment 42

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 143892 [details] [diff] [review]
Same as diff -w

OK, I've been running with this for a bit, and I've not run into any problems. 
I think this is safe enough for 1.7.

Comment 43

[Brendan Eich [:brendan]]

Comment on attachment 143892 [details] [diff] [review]
Same as diff -w

a=[e-mail] for 1.7 final.

/be

Comment 44

[Boris Zbarsky [:bzbarsky]]

Checked in for 1.7.  Thanks to roc for doing the hard part!