396726 - Serious performance regression in dealing with binary-data-as-text document on Linux

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Boris Zbarsky [:bzbarsky]]

BUILD: Current trunk Linux build

STEPS TO REPRODUCE:
1)  Download https://bugzilla.mozilla.org/attachment.cgi?id=281427 and save it
    to a text file locally.
2)  Create an HTML document with a single <iframe width="100%" height="100%">
    in it that includes the text file (this allows timing the load in the HTML
    document).
2)  Open that HTML document in the browser.

EXPECTED RESULTS: Fairly quick rendering and painting

ACTUAL RESULTS: Initial rendering takes 7-8 seconds on trunk (as compared to under a second on the 1.8 branch).  Repaints are very slow (hang the X server for a second or two every time you mouse into or out of the window).

Profiling one of those repaints shows the time is about 50-50 split between native them background rendering (presumably of the scrollbars?) and text painting.  The latter spends a lot of its time under XRenderCompositeText8/16 as called from GlyphBuffer::Flush, but there's also some _cairo_pattern_acquire_surface, _cairo_scaled_glyph_lookup, etc.

Setting the HTML document's root to "overflow:hidden" reduces the pageload time by about 50%.

Amusingly enough, the time under background painting shows a lot of time spent under gdk_x11_font_get_name, which various things call by calling gdk_gc_set_values.

Comment 1

[Michael Ventnor]

Wrong link? I get a semi-NSFW picture.

Comment 2

[Michael Ventnor]

For the record though, I don't have any experience with Xlib at all (Ive only been using GTK up to this point), so if the cause is there then I wouldn't have a clue what to do.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Wrong link? I get a semi-NSFW picture.

Right link.  That's why you have to locally save it to a text file.  It used to be text/plain in that bug when initially posted, if you look at the bug info, but that's been changed.

> For the record though, I don't have any experience with Xlib at all 

Sure.  I cced you because the gtk native theming is involved.  I'll post the profile in case it tells you anything.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: zipped-up profile with --sync

Comment 5

[Michael Ventnor]

I get an initial freeze of about 3 seconds, but after that everything is fine for me. No freeze after moving mouse out of the window or lagging or anything.

My build is a bit old(ish) though
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007091510 Minefield/3.0a8pre

Comment 6

[Boris Zbarsky [:bzbarsky]]

It's when you move back in that it's slow...  About a second here; presumably less on your faster hardware.  Watching a CPU meter there is instructive,

In any case, try the same on branch to see the difference.

Comment 7

[Michael Ventnor]

That's what I meant sorry, moving the mouse back in shows no problems. And I doubt I have faster hardware, I have a 2.0GHz Pentium 4 with 512MB of RAM; nonetheless I'll look at branch.

Comment 8

[Stuart Parmenter]

362682 might fix/make this better

Comment 9

[Stuart Parmenter]

as filed, i don't believe this is really a blocker -- don't load binary
documents as text.  if you have certain unicode documents that are really slow
due to font fallback, those should probably block.

Comment 10

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

I think this should block, because this does happen in the wild. For example, http://mxr.mozilla.org/seamonkey/search?string=CreateWindowEx
See bug 396732 comment #2.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> don't load binary documents as text

No one does this on purpose.  It'll just happen more and more often as sites switch to the new Apache version which sends "text/plain; charset=UTF8", which we don't sniff for being binary.

Renominating based on the fact that this will bite real users.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> 362682 might fix/make this better

I tried applying that patch, but 'patch' claims that the cairo-ft-font.c hunks are already in while the others are not or something.  I'll retest once that lands.

Comment 13

[Stuart Parmenter]

is this better with current trunk builds?

Comment 14

[Damon Sicore (:damons)]

Minusing and marking as wanted-1.9.  Per discussion with Vlad and Stuart.  Improvements in the underlying platform will improve this as well.  It would be great to get help from the linux distros on this.  If someone wants to work on this, feel free to take it.  

Comment 15

[Boris Zbarsky [:bzbarsky]]

Attachment: The testcase

Comment 16

[Boris Zbarsky [:bzbarsky]]

> is this better with current trunk builds?

The initial load is about 25% faster than before the patch for bug 362682 (so still a lot slower than branch).  Mousing in or out of the window is actually _slower_ now than it was before the patch for bug 362682.  I get a CPU spike and pretty much unresponsive browser for over two seconds every time.

Note that in between filing this bug and now I upgraded my pango from 1.6 to 1.12.  That cut the time for initial load from 8 seconds to 4 seconds.  It didn't affect the hang on mouse in/out, as far as I can tell.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Interestingly, if I mouse in/out really fast, the CPU usage is actually lower.  I have no idea why: we cache textruns for 30 seconds or so, right?  So it's not like they're being evicted....

Of further interest, I get that hang with mozilla.org builds, but not with my own (profiling enabled) build.

Comment 19

[u279076]

I am closing this bug as WORKSFORME since I am unable to reproduce this bug with Firefox 47.0.1 nor Nightly 50.0a1 on Ubuntu 16.04.1 64-bit. Boris please reopen this bug report if it still reproduces.