Issue metadata
Sign in to add a comment
|
10.2%-10.5% regression in blink_perf.svg at 388910:388960 |
||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Apr 25 2016
=== Auto-CCing suspected CL author jinsukkim@chromium.org === Hi jinsukkim@chromium.org, the bisect results pointed to your CL below as possibly causing a regression. Please have a look at this info and see whether your CL be related. ===== BISECT JOB RESULTS ===== Status: completed ===== SUSPECTED CL(s) ===== Subject : Reland "UTF-8 detector for pages missing encoding info" Author : jinsukkim Commit description: TextResourceDecoder is designed (or used) in such a way that the text encoding of a document gets resolved from the first chunk (as big as 4096 bytes) of the text received from network - by BOM, meta tag, or auto encoding detection (if enabled). The newly introduced UTF-8 encoding detector crrev.com/1721373002 was reverted ( crbug.com/603558 ) because it attempted to work in a bit different way - it examined all the subsequent chunks as well in search of non-ASCII-UTF-8-encoded char sequence. This means it is possible for TextResourceDecoder to start with a codec for, say, windows-1252, and then later switch to one for UTF-8. Theoretically this should still work but doesn't in practice (maybe hasn't been used/tested in that way). This is what happened with failed perf tests - one of the js files was big (13K), of pure ASCII except one tiny char sequence \xc2\xa7 almost at the end. The CL was updated so the UTF-8 encoding detection also works against the first chunk only like other methods, to avoid potential codec switching in the middle. BUG= 583549 , 603558 Review URL: https://codereview.chromium.org/1890103002 Cr-Commit-Position: refs/heads/master@{#388927} Commit : 57139d64c5b98142ca9305792f39ae23a4950375 Date : Thu Apr 21 22:35:47 2016 ===== TESTED REVISIONS ===== Revision Mean Value Std. Dev. Num Values Good? chromium@388919 59.279 0.94382 5 good chromium@388924 59.6432 0.623485 5 good chromium@388926 59.9152 0.875503 5 good chromium@388927 66.0578 1.444041 5 bad <- chromium@388928 64.5256 0.874496 5 bad chromium@388937 65.173 0.684897 5 bad Bisect job ran on: mac_10_11_perf_bisect Bug ID: 606267 Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests blink_perf.svg Test Metric: WorldIso/WorldIso Relative Change: 9.94% Score: 99.9 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_11_perf_bisect/builds/601 Job details: https://chromeperf.appspot.com/buildbucket_job_status/9014426787236392816 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=606267 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Tests>AutoBisect. Thank you!
,
Apr 26 2016
,
Apr 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/472f4e7c9b1ce63e453be41e938520dec30af46b commit 472f4e7c9b1ce63e453be41e938520dec30af46b Author: jinsukkim <jinsukkim@chromium.org> Date: Tue Apr 26 22:37:08 2016 Add XML header to test SVG file WorldIso.svg is the only file in the SVG performance test suite that's missing the xml header. This triggered auto-encoding detector or UTF-8 encoding detector and caused extra amount of time in the result, which is not the purpose of the test suite. Added a header used in other svg (Worldcup.svg). This fixes the regression reported in blink_perf.svg. BUG= 606267 Review URL: https://codereview.chromium.org/1922843002 Cr-Commit-Position: refs/heads/master@{#389923} [modify] https://crrev.com/472f4e7c9b1ce63e453be41e938520dec30af46b/third_party/WebKit/PerformanceTests/SVG/resources/WorldIso.svg
,
Apr 26 2016
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by toyoshim@chromium.org
, Apr 25 2016