Hi Ben, tanks for respond. I don't think is about nodejs, because valgrind says that bottleneck is:
v0.4 v8::Internal::Runtime_ParseJson with 10 calls (that is expected) and inclusive costs 68.1% but v0.10 v8::Internal::Runtime_ParseJson with 10 calls (expected) and inclusive costs 51.5% it's less, but GC in v0.10 is too active (too much calls). Can I reduce his activity? вторник, 16 сентября 2014 г., 14:18:23 UTC+3 пользователь Ben Noordhuis написал: > > On Tue, Sep 16, 2014 at 9:24 AM, <[email protected] <javascript:>> wrote: > > Hi all, > > > > I'm trying investigate time and memory degradation v0.4.12(771ba3) vs > > 0.10.15(64a1f0). > > > > Build: > > ./configure --prefix=path/to/binary && make && make install > > > > Input: > > //bench.js > > var fs = require('fs'); > > var data = fs.readFileSync('input.json', 'utf8'); > > > > var p0 = JSON.parse(data); > > var p1 = JSON.parse(data); > > var p2 = JSON.parse(data); > > var p3 = JSON.parse(data); > > var p4 = JSON.parse(data); > > var p5 = JSON.parse(data); > > var p6 = JSON.parse(data); > > var p7 = JSON.parse(data); > > var p8 = JSON.parse(data); > > var p9 = JSON.parse(data); > > > > //input.json (~100Mb) > > { > > "\u0041": 1, > > "\u0042": 1, > > ,................ > > "\u0045": 1, > > "\u0046": 1, > > } > > > > Results for: /usr/bin/time -f "%U %S %M" ./node bench.js > > v0.10 > > 0.11 0.01 263088 > > > > v0.4 > > 0.04 0.00 98800 > > > > Results for: ./node --trace_gc bench,js > > v0.10 > > [19743] 47 ms: Scavenge 2.5 (38.3) -> 2.5 (39.3) MB, 0.7 ms > > [allocation failure]. > > [19743] 81 ms: Scavenge 3.5 (39.3) -> 3.4 (40.3) MB, 0.9 ms > > [allocation failure]. > > [19743] 83 ms: Scavenge 4.2 (40.3) -> 4.2 (40.3) MB, 0.5 ms > > [allocation failure]. > > [19743] 85 ms: Scavenge 5.9 (40.3) -> 5.9 (42.3) MB, 1.2 ms > > [allocation failure]. > > [19743] 88 ms: Scavenge 7.4 (42.3) -> 7.4 (43.3) MB, 1.5 ms > > [allocation failure]. > > [19743] 96 ms: Scavenge 11.2 (44.3) -> 11.2 (45.3) MB, 4.1 ms > > [allocation failure]. > > [19743] Increasing marking speed to 3 due to high promotion rate > > [19743] 106 ms: Scavenge 12.8 (46.3) -> 10.3 (46.3) MB, 1.4 ms (+ > 2.5 > > ms in 25 steps since last GC) [allocation failure]. > > [19743] 117 ms: Scavenge 16.8 (46.3) -> 16.7 (51.3) MB, 4.7 ms (+ > 1.5 > > ms in 3 steps since last GC) [allocation failure]. > > [19743] 123 ms: Mark-sweep 17.1 (51.3) -> 9.5 (48.3) MB, 5.6 ms (+ > 4.1 > > ms in 28 steps since start of marking, biggest step 0.0 ms) [StackGuard > GC > > request] [GC in old space requested]. > > [19743] 139 ms: Scavenge 25.3 (48.3) -> 17.6 (51.3) MB, 7.7 ms > > [allocation failure]. > > [19743] 147 ms: Scavenge 29.3 (51.3) -> 17.2 (52.3) MB, 1.4 ms > > [allocation failure]. > > [19743] 161 ms: Scavenge 30.2 (52.3) -> 21.2 (55.3) MB, 5.8 ms > > [allocation failure]. > > [19743] 175 ms: Scavenge 33.1 (55.3) -> 25.9 (60.3) MB, 8.5 ms > > [allocation failure]. > > [19743] 185 ms: Scavenge 37.8 (60.3) -> 26.5 (61.3) MB, 3.2 ms > > [allocation failure]. > > > > v0.4 > > Scavenge 2.6 -> 2.3 MB, 0 ms. > > Mark-sweep 3.1 -> 2.6 MB, 1 ms. > > Scavenge 3.9 -> 3.8 MB, 0 ms. > > Scavenge 5.0 -> 4.8 MB, 0 ms. > > Scavenge 6.0 -> 5.7 MB, 0 ms. > > Mark-sweep 6.9 -> 6.5 MB, 3 ms. > > Scavenge 11.1 -> 10.3 MB, 1 ms. > > > > > > Results for: ./node --prof --log-snapshot-positions bench.js && > > ./tools/linux-tick-processor > > --snapshot-log=out/native/obj.target/v8_snapshot/geni/snapshot.log > > tools/linux-tick-processor ../../build/bin/v8.log > > v0.10 > > Statistical profiling result from tools/linux-tick-processor, (0 ticks, > 0 > > unaccounted, 0 excluded). > > > > v0.4 > > can't build it > > > > > > I read change logs and commits/changes for node.js and v8 engine form > 0.4 to > > 0.10 but didn't find helpful information so far. > > Can someone give me advice where I should search? > > Your question might get more responses on the nodejs mailing list but > I'll answer what I can. > > The fact that the tick processor reports 0 ticks is probably either > due to a mismatch between the tick processor script and the V8 version > that generated the v8.log or because the script didn't run long enough > to gather meaningful statistics. > > The script runs to completion in ~110 ms with v0.10 but it's likely > start-up time dominates. v0.10 starts up much slower than v0.4, > relatively speaking, but that's because it does a lot more. > > I see you noticed that the garbage collector behaves differently. The > GC in v0.10 is tuned for interactivity; that is, it tries to amortize > GC time by doing frequent "small" collections in order to avoid long > pauses in "large" collections. > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
