GWT application [Internal to google] slows down significantly on Mac OS |
|||||||||||
Issue descriptionChrome Version : 51.0.2704.36 OS Version: OS X 10.11.4 URLs (if applicable) : go/pez (google internal) Other browsers tested: NOT TESTED. The app is Chrome only What steps will reproduce the problem? Ran bisect-builds-py and got this: You are probably looking for a change made after 376961 (known good), but no later than 376966 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/e4875bd7847cc510da66a2ae6fc7206c6045eb4f..b97dbebc4f4b202b8278629e473642370f0dd224 Some more information about the issue in beginning of this post. https://groups.google.com/a/google.com/forum/#!topic/chrome-discuss/jQ_yx3juqyQ Please provide any additional information below. Attach a screenshot if possible. This is an internal google app built with GWT. I can email the details once someone in Google starts looking into it. UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.36 Safari/537.36
,
May 10 2016
Hi, What's the policy for setting the priority? Considering that this is happening in stable as well as beta versions, can this be bumped up?
,
May 11 2016
,
May 11 2016
In what way did this GWT application slow down?
,
May 11 2016
Chris, You access is now added to the UAT version of the tool. The link is go/pez-uat Once the page loads, try scrolling down and you'll see the problem. On a macbook (chrome 50.0.2661.94 (stable) or 51.0.2704.36 (beta)), the page doesn't scroll or it's very slow. But you can scroll and see everything on Ubuntu. It works on a macbook only if you use v49. I have narrowed it down further with the bisect-builds-py. Please see above. Please let me know if you are not able to view the page. Thanks Arun
,
May 12 2016
--disable-prefer-compositing-to-lcd-text causes the app to become responsive again. Something is pretty wrong with compositing scrolling in this case.
,
May 12 2016
,
May 12 2016
That bisect doesn't include any CLs that seem to make sense. Requesting another one. I think something is wrong with the composited scrolling machinery in this case.
,
May 12 2016
Ran the bisect again and got this. It's different from previous one. When I ran it yesterday, I had to restart it in the middle when the script hung up on me (may be the browser didn't quit correctly). I think I picked the wrong numbers upon restart and it should have messed up the bisect. Anyway, I am attaching the full run here and this one looks good. arunkj-macbookpro:chrome-debug arunkj$ python ./bisect-builds.py -a mac -g 369907 -b 378081 Downloading list of known revisions... (use --use-local-cache to cache and re-use the list of revisions) Downloading revision 373758...ac/a98ef4b50cff7611a03cc77c194e5637be5e2d7f/ Received 87347555 of 87347555 bytes, 100.00% Bisecting range [369908 (good), 378073 (bad)]. Trying revision 373758... Revision 373758 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 375704... Bisecting range [373758 (good), 378073 (bad)]. Trying revision 375704... Revision 375704 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 376790... Bisecting range [375704 (good), 378073 (bad)]. Trying revision 376790... Revision 376790 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 377512... Bisecting range [376790 (good), 378073 (bad)]. Trying revision 377512... Revision 377512 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 377206... Bisecting range [376790 (good), 377512 (bad)]. Trying revision 377206... Revision 377206 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 376966... Bisecting range [376790 (good), 377206 (bad)]. Trying revision 376966... Revision 376966 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 376997... Bisecting range [376966 (good), 377206 (bad)]. Trying revision 376997... Revision 376997 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 377030... Bisecting range [376997 (good), 377206 (bad)]. Trying revision 377030... Revision 377030 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 377106... Bisecting range [377030 (good), 377206 (bad)]. Trying revision 377106... Revision 377106 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 377152... Bisecting range [377106 (good), 377206 (bad)]. Trying revision 377152... Revision 377152 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 377129... Bisecting range [377106 (good), 377152 (bad)]. Trying revision 377129... Revision 377129 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b You are probably looking for a change made after 377106 (known good), but no later than 377129 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/b8812fef3cb23bbb30ccfd2884aba1ee60681346..1100744b50b4b901c9b1d19506128222fd773d6a arunkj-macbookpro:chrome-debug arunkj$
,
May 12 2016
Hmm. None of the changes in that bisect range look like they could have caused this...
,
May 13 2016
Can you run the bisect that I ran above? You should be able to see the issue against pez uat.
,
May 18 2016
Chris, Any updates on this issue? Thanks
,
May 18 2016
I'm working on it.
,
May 18 2016
The patch that slows things down is: https://codereview.chromium.org/1725553002 Since the app starts locking up, I think there is probably a lock contention/deadlock issue.
,
May 18 2016
--enable-prefer-compositing-to-lcd-text is required to repro on a non-retina device.
,
May 18 2016
arunkj could you please give ericrk access to the site?
,
May 19 2016
Thanks for bisecting - I'm happy to investigate. The memory logging added in that patch didn't turn out to be too useful, so I may just revert if it looks like the slowness is unavoidable.
,
May 19 2016
Eric, your access was granted for go/pez-uat.
,
May 19 2016
Eric, do you know when a fixed version would be available for us to download (beta or stable)? The number of users reporting the issue in our case is dependent on their access levels and also the chrome update schedule. The more people get their versions automatically updated to v50+ the worse it is for us. It would be great if there is a version which we can point them to when they encounter the bug. Thanks
,
May 19 2016
I'll get a fix in today - this will make it in to Chrome 52 beta, which should be available next week (I believe 51 will be stable next week as well, but that won't have the fix). I'm not sure if the severity of the issue will allow for a merge to stable - I'll follow up once I've determined what the fix is.
,
May 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/573c2559f7d9fa330b03095a86cdc2744e0a661b commit 573c2559f7d9fa330b03095a86cdc2744e0a661b Author: ericrk <ericrk@chromium.org> Date: Thu May 19 20:08:51 2016 Revert "Dump DisplayListRasterSource memory" This reverts commit 83e6b8ebbad5c764903c346d8917b8d35dadb35d. BUG= 610734 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review-Url: https://codereview.chromium.org/1989813004 Cr-Commit-Position: refs/heads/master@{#394847} [modify] https://crrev.com/573c2559f7d9fa330b03095a86cdc2744e0a661b/cc/playback/raster_source.cc [modify] https://crrev.com/573c2559f7d9fa330b03095a86cdc2744e0a661b/cc/playback/raster_source.h
,
May 19 2016
This change likely introduced a significant performance regression on sites with a lot of layers (such as the GWT site which this bug was filed for). The revert should be very safe (just taking us back to our previous behavior). Would like to merge this to M51 beta if possible.
,
May 19 2016
Merge approved for M51 (branch 2704)
,
May 19 2016
Please merge your change ASAP, as we are very close to M51 stable candidate cut.
,
May 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9d6442714b18b31b7c44efc6dc4ad88d11e4092b commit 9d6442714b18b31b7c44efc6dc4ad88d11e4092b Author: Eric Karl <ericrk@google.com> Date: Thu May 19 22:12:27 2016 Revert "Dump DisplayListRasterSource memory" This reverts commit 83e6b8ebbad5c764903c346d8917b8d35dadb35d. BUG= 610734 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review-Url: https://codereview.chromium.org/1989813004 Cr-Commit-Position: refs/heads/master@{#394847} (cherry picked from commit 573c2559f7d9fa330b03095a86cdc2744e0a661b) Review URL: https://codereview.chromium.org/1997913002 . Cr-Commit-Position: refs/branch-heads/2704@{#609} Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251} [modify] https://crrev.com/9d6442714b18b31b7c44efc6dc4ad88d11e4092b/cc/playback/raster_source.cc [modify] https://crrev.com/9d6442714b18b31b7c44efc6dc4ad88d11e4092b/cc/playback/raster_source.h
,
May 19 2016
This should be fixed in tomorrow's Canary, as well as M52 Beta, when that releases. It was also merged into M51, so it should be available in M51 stable, once that releases. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by asvitk...@chromium.org
, May 10 2016