main thread getting descheduled has huge performance impact on TodoMVC PLT |
||||||||
Issue descriptione.g. ChromiumPerf/linux-release/v8.todomvc/v8_execution_time_self/AppLoad/Closure - if we don't get descheduled, there's about 20ms V8 execution wall time, but if we get descheduled, the wall time goes up to >50ms. For the sake of getting a nicer graph, I'll probably switch to cpu time, however, wall time is what users see. There's nothing else going on in the renderer, why are we being descheduled that aggressively?
,
Mar 29 2016
,
Mar 29 2016
Any way to get a trace of the badness in action?
,
Mar 29 2016
I changed the benchmark to record * (chrome-perf also records the traces of the actual runs, but they only include v8 and console.log categories) The good run is 29ms (v8 execution time self) and the bad run is 41ms
,
Mar 29 2016
What does Safari look like running the same benchmark?
,
Mar 29 2016
I don't know how to extract pure JSC time from Safari - just looking at the benchmark, the small variance in v8 execution time is drowned in the variance of the rest of the system.
,
Aug 10 2016
,
Aug 10 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 14 2017
,
Aug 14 2017
,
May 8 2018
,
Aug 15
Closing this bug as WontFix as a part of scheduling bug review. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by jochen@chromium.org
, Mar 29 2016