GC takes over 20% of the time in complex Ember performance test |
||||||||||||||
Issue descriptionLooking into "Render Complex List (HTML)" from http://emberperf.eviltrout.com/, it seems that we spend over 20% of the time in the GC (according to chrome://tracing). That seems like a lot compared to what we see normally. Probably worth investigating, especially since --trace-gc doesn't show a lot of garbage being collected.
,
Apr 13 2017
,
Apr 13 2017
,
Apr 13 2017
,
Apr 13 2017
Lets not mix up issues here. If the error rates are of concerns then please open another issue. I am not looking at the benchmark results but at the runtime call stats. The problem seems to be that the scavenge times are pretty high. Even on our Z840 they can be around 40ms. I did a quick check with the minor mark compact prototype I am trying to finalize this quarter. The prototype is still bit buggy, i.e., not every run succeeds. I also doesn't yet moves pages, but already makes use of some concurrency for moving around objects. This seems to reduce the GC times from 20% to around ~12%.
,
Aug 21 2017
The parallel scavenger landed, so it is time for re-evaluation. $ cat out-base.log | grep gc=s | ~/workspace/v8/v8/tools/eval_gc_nvp.py pause pause len: 231 min: 1.4 max: 28.4 avg: 11.2766233766 [0,5[: 34 [5,10[: 58 [10,15[: 99 [15,20[: 27 [20,25[: 11 [25,30[: 2 $ cat out-parallel.log | grep gc=s | ~/workspace/v8/v8/tools/eval_gc_nvp.py pause pause len: 194 min: 1.2 max: 15.6 avg: 6.52422680412 [0,5[: 16 [5,10[: 166 [10,15[: 10 [15,20[: 2 Scavenge pauses are reduced by 42% in this benchmark when looking at NVP logs. Looking at RCS (traced attached) we are down to 10% GC time from the initial 20% in #0; that's 2x. I think we can mark this as fixed now.
|
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by bmeu...@chromium.org
, Apr 13 2017368 KB
368 KB View Download
618 KB
618 KB View Download