If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED WORKSFORME

Status

()

Core
Graphics
RESOLVED WORKSFORME
10 years ago
a year ago

People

(Reporter: bz, Unassigned)

Tracking

({hang, perf, regression})

Trunk
x86
Linux
hang, perf, regression
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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.
Flags: blocking1.9?
Keywords: regression

Comment 1

10 years ago
Wrong link? I get a semi-NSFW picture.

Comment 2

10 years ago
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.
> 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.
Created attachment 281570 [details]
zipped-up profile with --sync
Attachment #281570 - Attachment is patch: false
Attachment #281570 - Attachment mime type: text/plain → application/zip

Comment 5

10 years ago
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
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

10 years ago
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

10 years ago
362682 might fix/make this better

Comment 9

10 years ago
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.
Flags: blocking1.9? → blocking1.9-
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.
> 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.
Flags: blocking1.9- → blocking1.9?
> 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.
Depends on: 362682

Comment 13

10 years ago
is this better with current trunk builds?
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.  
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Created attachment 284310 [details]
The testcase
> 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.
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.
Duplicate of this bug: 390052
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
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.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.