(Assigning per request in  bug 690144 )

This doesn't seem to be related to the fix for  bug 690144 . I sent mbostock a version of Chromium with the fix disabled and the slowdown still happened.

It's also been difficult to duplicate here -- I've tried on four separate Macs, and a couple of other people have tried it on theirs, and we haven't seen it. However, it's been verified by others in the wild.

mbostock, what GPU/video card do you have on your system?

Intel Iris Graphics 6100 1536 MB

Other details:
macOS Sierra 10.12.3
MacBook Pro (Retina, 13-inch, Early 2015)
3.1 GHz Intel Core i7
16 GB 1867 MHz DDR3

Performance with GPU Rasterization looks reasonable on my MBP with Intel Iris Pro, however I am seeing some rendering bugs at normal content scale.

See screenshot, which shows triangles between unrelated elements.

Deleted: Screen Shot 2017-03-08 at 11.04.29 AM.png 809 KB

	Screen Shot 2017-03-08 at 11.04.29 AM.png 809 KB View Download

The bug in #5 occurs on 57.0.2987.88 Beta, but not on 59.0.3035.0 Canary.

@vmiura that would be  bug 690144 .

I want to reiterate that the slowness does seem to have an interaction with the developer tools, that is, opening the developer tools makes the slowness go away. In Canary 59, it’s only slow if I open the test case linked above in a new window (that has never had the developer tools open). If I open the developer tools for that window and reload, the test case re-renders quickly—even if I subsequently close the developer tools.

Sorry I should have read  bug 690144  which is the issue in #5.

mbostock@ could you please record a trace while the page is loading with chrome://tracing?

Attached a trace on my MBP, which takes a couple of seconds to load.  Skia & GPU appear to not be a bottleneck at all.  The loading is bottlenecked by the background parsing of the SVG.  I'm curious to see the difference in your trace.

Deleted: trace_lots-of-svg-circles.json.gz 432 KB

trace_lots-of-svg-circles.json.gz 432 KB Download

Did you want a “Web Developer” trace or a “Rendering” trace? I wasn’t sure so I guessed the latter but I can redo if you want the other one.

Deleted: trace_trace-circles-renderer.json.gz 871 KB

trace_trace-circles-renderer.json.gz 871 KB Download

For comparison, here is a fast render on my laptop after opening and closing the devtools and reloading the page.

Deleted: trace_circles-after-devtools-rendering.json.gz 505 KB

trace_circles-after-devtools-rendering.json.gz 505 KB Download

Thanks for the traces.  It does look like parsing got much slower.

Slow case -
HTMLDocumentParser::processTokenizedChunkFromBackgroundParser	
 Wall duration 13,085.906 ms
 CPU duration 12,990.214 ms

Fast case -
HTMLDocumentParser::processTokenizedChunkFromBackgroundParser	
 Wall duration 499.837 ms
 CPU duration 481.262 ms

Re-add the SVG label if this turns out to be something we can address with SVG changes.

Able to reproduce this issue on Mac 10.12.3 MacBook Pro-Retina with chrome version #56.0.2924.87, but unable to reproduce this issue on latest stable & Beta #57.0.2987.98, Dev #58.0.3029.19, Canary #59.0.3042.0

Attaching the screen-cast for reference.

mbostock@ could you please update the chrome to latest version to retest the same scenario and let us know your observations.

Deleted: Issue 695466-1.png 905 KB

	Issue 695466-1.png 905 KB View Download

Deleted: Issue 695466-2.png 1.1 MB

	Issue 695466-2.png 1.1 MB View Download

Deleted: Issue 695466-gpu.htm 49.1 KB

Issue 695466-gpu.htm 49.1 KB View Download

I retested Version 59.0.3043.0 canary (64-bit) and my observation is the same. It is slow, but fast if you open the developer tools and reload. (And slow again if you close the window and open a new window; that is, it is only fast if the developer tools have been opened at least once for the current window.)


On Version 56.0.2924.87 (64-bit), it is fast regardless of the state of the developer tools. However the rendering is incorrect per  bug 690144 . I will report back in the latest mainstream release shortly.

On Version 57.0.2987.110 (64-bit), I am unable to reproduce the slowness. It is fast (and correct!) regardless of the state of the developer tools. 👏

Unable to reproduce this issue on Mac Sierra 10.12.3 with Chrome #59.0.3044.0, observed that SVG rendered in few seconds, without opening any devtools

Attached screen-shot for reference.

mbostock@ could you please retry the same scenario on clean profile with no apps & extensions and let us know your observations.


Thank You...

Deleted: 695466-1.png 1.1 MB

	695466-1.png 1.1 MB View Download

I installed Canary specifically to assist with  bug 690144  and have not used it for anything else, so it still has a clean profile with no apps or extensions. However, I have now also verified that create a new clean profile has no effect: performance is slow until the developer tools are opened.

Previous comment was using Version 59.0.3044.0 canary (64-bit).

It's odd but I can't reproduce this with official builds, but I could reproduce this with Chromium mac64 builds and linux64 at ToT (eg r463487) and a long way into the past (M55; I did not look further back.)

If anyone has trouble reproducing, I did this:

tools/bisect-builds.py --use-local-cache -g 463489 -b 463156 -a linux64 --verify-range -- --no-first-run https://bl.ocks.org/mbostock/raw/58cc9fb39d3e1fef81eb8fb557e08c96/

It would be good to confirm whether this is processTokenizedChunkFromBackgroundParser and what it is doing.

Executed the following bisect script in reverse on Mac pro sierra 10.12.4 "bisect-builds.py -g 463489 -b 463156 -a mac -- --no-first-run https://bl.ocks.org/mbostock/raw/58cc9fb39d3e1fef81eb8fb557e08c96/" , it has given all good builds

dominicc@ could you please look into it.  

I ran that (with --use-local-cache) and they're all bad. (How are you judging good and bad?)

dominicc@ i attaching the screen-shots of good and bad behavior.

for good build, the page should be loaded with in 4-6 seconds irrespective of devtools.

Deleted: Issue 695466-Good.png 1.1 MB

	Issue 695466-Good.png 1.1 MB View Download

Deleted: Issue 695466-bad.png 905 KB

	Issue 695466-bad.png 905 KB View Download

I think that broken rendering is a different issue. This issue is about speed.

Team, can someone triage with the latest chrome version and update the behaviour.

Unable to reproduce the issue on macbook Pro (Retina, 15-inch, Mid 2014)10.12.6 using chrome latest version #62.0.3173.0 and latest beta/stable #60.0.3112.78.

Attached screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to URL: https://bl.ocks.org/mbostock/raw/58cc9fb39d3e1fef81eb8fb557e08c96/ with dev tools not open.
2. Observed that SVG rendered in a few seconds as expected.

mbostock@ - Could you please check the issue in latest chrome version #62.0.3173.0 and please let us know if the issue persist or not.

Thanks...!!

Deleted: 695466.mp4 1.2 MB

	695466.mp4 1.2 MB View Download

I confirm that the slowness persists in both Chrome Version 62.0.3173.0 (Official Build) canary (64-bit) and Version 60.0.3112.78 (Official Build) (64-bit). (And as before, opening the developer tools on this window causes the slowness to go away, making it render quickly on refresh.)

Please let me know if there is any additional information I can provide to assist with this issue. Thank you!

Able to reproduce this issue on Windows 10, Ubuntu 14.04 and MacBook Air 10.12.6 with chrome #61.0.3163.79 and Canary #63.0.3206.0 and also in earlier M50 version.

Observations:
1. Issue is not observed in normal window, in normal window test page is rendering within 3-5 seconds as shown in comment #29.
2. Issue is only observed in InCognito window, it has taken 13-15 seconds to render the test page.

Attaching the screen-cast for reference.

mbostock@ could you please try the scenario on incognito window and let us know your observations.

Note: Removing bisect label for now, will add once we have consistent repro steps.

Deleted: 695466.mp4 1.8 MB

	695466.mp4 1.8 MB View Download

I confirm kkaluri@’s observation on Chrome 61.0.3163.79, macOS 10.12.6. The test URL loads quickly in a normal window, but slowly in the incognito window. Opening and closing the developer tools in the incognito window, followed by focusing the title bar and hitting ENTER to refresh, makes the page load quickly.

In Canary 63.0.3210.0, the test URL loads slowly in both normal windows and incognito windows. Opening and closing the developer tools makes the slowness go away.

I took a look at this with callstack sampling enabled on Windows in Chrome 62.0.3202.9 (Official Build) dev (64-bit) (cohort: Dev) and the profiles showed SVG allocation causing GC a lot.

Creating an SVGCircleElement allocates a bunch of objects including the circle itself and an animated path length.

I don't know yet why the GC is ineffective or why we're hitting this path so much when devtools was not open.

I looked at this in tracing and it seems to confirm the GC in HTMLDocumentParser::processTokenizedChunkFromBackgroundParser story. In both cases processing a chunk starts out taking ~2ms, but then in the "slow" case it starts taking much more, like 50-100ms and with frequent collections and ThreadState::collectionRate is reportedly 0.

This should be of interest to the Oilpan team.

The slow case seems to always trigger an Oilpan conservative GC because wrapper_count_at_last_gc_ is zero. wrapper_count_at_last_gc_ should not be zero except the beginning.

I will investigate why wrapper_count_at_last_gc_ is zero only in the incognito window.

Thanks Keishi.

It is understandable that no wrappers have been collected because the page isn't running script. It is just allocating a bunch of CSS circles.

Just out of curiosity what's the coupling between those two things--collecting wrappers and conservatism? Conservative means you're going to scan the stack, right?

It's not really related. We estimate the amount of garbage we can collect to trigger BlinkGC. One of the strong signals used to estimate this is the "decrease in # of wrappers since last GC". (If V8 collects the wrapper, the Blink-side object is likely to be released as well) It looks like the BlinkGC scheduling code was not written for zero wrapper count in mind (We early return with "yes run GC")

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/13ce8f521d57f624eed2588e6bc30713e376a55d

commit 13ce8f521d57f624eed2588e6bc30713e376a55d
Author: Keishi Hattori <keishi@chromium.org>
Date: Tue Sep 12 01:56:04 2017

BlinkGC: Fix ThreadState::EstimatedLiveSize for webpages with no JS

ThreadState::EstimatedLiveSize always returns 0 for webpages with no JS because WrapperCountAtLastGC is always 0.
This caused GCs to (almost) always trigger.
By returning estimation_base_size in this case, we can maintain the existing behavior before the first GC, but return the appropriate estimated live size for any calls after the first GC.

Bug:  695466 
Change-Id: I76972e07d00a27aa14e3204bf77dada51fa00c95
Reviewed-on: https://chromium-review.googlesource.com/659718
Commit-Queue: Keishi Hattori <keishi@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501152}
[modify] https://crrev.com/13ce8f521d57f624eed2588e6bc30713e376a55d/third_party/WebKit/Source/platform/heap/ThreadState.cpp

The NextAction date has arrived: 2017-09-18

I tried this in 63.0.3218.4 (Official Build) canary (64-bit) (cohort: Clang-64) and the changed GC heuristic has improved it.

Might be worth looking for other similar issues where pages without script that do a lot of allocations are slow in this way. This should fix those pages.

Keishi was there anything else you planned to do for this? If so feel free to reopen it.

Thanks for playing everyone.