"Commit" phase taking extremely long time to complete in Chrome

[Peter Batory-Bernardin]

Hi all!

I'm not exactly sure if this is the right place for this, but I suspect this might be a bug in chrome, but maybe not - I don't know where else to ask.

I am a fairly advanced web developer and have created a complex app where there is a functionality that essentially calculates bounding rects of texts and uses canvas to draw highlights (an e-book reader).

As I was developing this, I always used 6x slowdown simulation to make sure it would never feel slow on a low-end device. It was always super fast anyway.

A few days ago I woke up (actually, last Saturday), and suddenly everything was extremely slow, even with no throttling. Dragging a highlight would take about two seconds per frame rather than 60 frames per second as it was the previous day.

So I thought I made an accidental mistake in my code, rolled back to a previous version in git to try and track the change that made this happen, and the same thing was happening. I rolled back to a week or two prior and it was still happening.

I opened my performance monitor and it didn't look like any kind of calculations were doing this, and I saw this: (see attached)

I'm trying to wrap my head around what exactly could be going on the commit phase, which shows no more information for me other than that it's a commit phase. Note that this does not happen in Safari, which is very snappy, which leads me to think it's something specific to Chrome's rendering pipeline.

I tried to isolate in my code exactly to find exactly what was happening. It doesn't actually seem to have anything to do with drawing in the canvas. When disable all calls to drawing APIS in the canvas, it still happens (e.g., I drag without any color being 'painted', but the commit phase is still 2 seconds per frame). Just the fact that the canvas is there seems to make it happen.

I want to understand what's going on in this mysterious "commit" phase. As I understand it, this phase is responsible for compositing different layers together ? Perhaps for some reason the canvas is involved in such a way that it's clogging something. This delay does seem to scale linearly with the size of the canvas.

The canvas itself is pretty big as it covers a whole scrollable page section at 2x resolution, but still, it's snappy in Safari and it was snappy in 6x slowdown the previous day (or I'm losing my mind). The slowdown seems linear to the size of the canvas.

What baffles me is that this only started happening on Saturday. Maybe there was an update to chrome that made this happen? Before it was extremely fast.

Any kind of insight in any way is helpful. I'm totally in the dark here. There's nothing for me to go on with the performance profiler.

Thanks!

[K. Moon]

This very well could be the result of a Chrome update. If you feel comfortable with trying to narrow it down yourself, you can use https://www.chromium.org/developers/bisect-builds-py/ to find a possible regression range. In any event, feel free to file a bug (ideally with a minimal reproduction case).

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/0417bfcc-d077-43e0-8ed4-e9639be4f6c6n%40chromium.org.

[Joe Mason]

You can also try running chrome with the "--enable-benchmarking" flag, which turns off some features that cause noise when running benchmarks. If that clears up the problem then the issue is probably with an experimental feature that was rolled out shortly before Saturday, and we can try to figure out which one.

Are you testing your app on the Chrome Dev channel? If so, hopefully we can find this regression before it hits Stable.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CACwGi-6y1F%2BBnzmMhaqA9SpzarZKa%2BZoRtiQScs7es3P6%2BjqAQ%40mail.gmail.com.

[Justin Novosad]

Unfortunately, the dev tools do not provide much insight into the inner workings of the browser's graphics pipeline, which is complex and involves multiple threads and processes. If you could share a simple HTML file that reproduces the performance bottleneck, I would be glad to analyze what is going on in more depth.  Please submit a bug (crbug.com/newissue) and add your repro case as an attachment (or link to a sandbox on jsfiddle.net, jsbin.com, etc.)  Thanks.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH%3DT95R%2BrspytSddOGF4NWZhVDQ%3DBLyROJsFya2Dt_YK2LQkkw%40mail.gmail.com.

[Stefan Zager]

If you have not yet, please file a bug at crbug.com.

If you're feeling adventurous, I'd be curious to see if running chrome with the following flag has any effect:

--enable-features=NonBlockingCommit

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABpaAqSU4AgmE_gNkf3ceWwi0nh62E9L6QbUo6iudz6jZ%2BN4Hg%40mail.gmail.com.

[Bruce Dawson]

I want to reemphasize the value (ease-of-use, precision of results) of bisect builds. In many cases just 10-30 minutes of testing with bisect builds will narrow down the regression range from thousands of commits to just a handful. You can specify the start and end ranges as a milestone (M113), version number, or a commit revision number.

I always recommend running the bisect builds script with --verify-range because that will check the specified good/bad points and verify that they capture the problem. Sometimes a performance regression will actually be caused by an experiment which suddenly got enabled in your browser, in which case bisect builds will not find it.