Issue metadata
Sign in to add a comment
|
LogDog takes ~1s for each layout operation in SyzyASAN build |
||||||||||||||||||||||||
Issue descriptionChrome Version: 63.0.3212.3 (Official Build) canary SyzyASan (32-bit) OS: Windows 10 What steps will reproduce the problem? (1) Upload a CL. (2) Do a CQ dry-run. (3) Pick a try-bot and click through to the compilation stdout (e.g. https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Ftryserver.chromium.android%2Fandroid_n5x_swarming_rel%2F259951%2F%2B%2Frecipes%2Fsteps%2Fcompile__with_patch_%2F0%2Fstdout) What is the expected result? Expect that the page loads reasonably quickly, and that if it does take a while to populate due to the networking being slow, it continues to download while you work in another tab. What happens instead? The page takes ~15 seconds to fully populate, and if you run a Dev Tools performance trace, about half of that time is spent in repeated re-layout operations, each of which takes ~1s to execute. The Layout operations are shown in Dev Tools with "Warning Forced reflow is a likely performance bottleneck.". If you switch to a different tab in the same window while the page loads then when you switch back it has not actually loaded any more, as though loading of the content is somehow dependent on repaint events.
,
Sep 19 2017
Loading the two links you provided, with Developer Tools' performance tracing enabled, I get: LogDog front-end: ~18s Plain-text: ~8s (This is loading on an Asus Chromebox, connected via Wi-Fi) Looking at the Developer Tools traces from these attempts, LogDog is spending bursts of 1-2s at a time doing layout in response to timer events. Plain-text is spending a lot of time on layout, but only(!) ~0.8s per re-layout. LogDog appears to do a 7.5MB fetch (~1.8s), followed by a 2.5MB one (12s), while Plain-text does a single request for 4.0MB of data, which takes 7.8s to fetch. Re-opening this bug since it seems that there are performance issues specific to LogDog, not just the layout overhead for large blocks of plain text.
,
Sep 23 2017
,
Aug 31
Hi wez. The old logdog viewer was replaced with a much simpler and faster one. Is it still slow in your cases? assigning for response
,
Sep 5
Re #4: Where would I find the new version? SyzyASAN builds got turned-down, but I can check whether the DCHECK-enabled builds see the (exaggerated) slowdown.
,
Sep 6
all new LUCI builds point to the new log viewer. Buildbot builds point to old viewer, but there is a link in the top inviting to try the new viewer. please provide examples of builders in form of links. I don't know which builders are DCHECK-enabled.
,
Sep 6
Re #6: This report is about loading the LogDog page, with a lot of output, into a Chrome instances with ASAN, or DCHECKs, enabled - the point was that if the allocator is slow (as is the case with ASAN) then LogDog was noticably worse, suggesting that Chrome was doing excessive allocation churn. I think this is basically an issue with the Blink layout engine, for large chunks of plain text?
,
Sep 6
If this is reproducible by opening a long plaintext file from disk, I'd probably put this in a different component other than logdog. Blink>Fonts or Blink>Layout maybe? This also reminds me of 690705
,
Sep 7
,
Sep 10
As far as the layout engine is concerned this is a known problem and one we're working on fixing, tracked in issue 636993. If there are logdog specific issues in addition to plain text rendering please file those separately. Thanks! |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by hinoka@chromium.org
, Sep 11 2017Status: Duplicate (was: Untriaged)