8 ms·

Looking at the linked benchmark file appears to bear out this claim: https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core_engine_benchmark.js#L207-L212

by bbllee 12y ago

Looking at the linked benchmark file appears to bear out this claim: https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core_engine_benchmark.js#L207-L212 https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... It appears that the reported numbers for benchmark X are _the # of times that X can be run before one second elapses_, so parent comment is correct and the premise of the blogpost (that the new node.js version with V8 has worse performance than the earlier version / the private fork has better performance than the new version and slightly worse performance than the old) is contradicted by the evidence presented. Not a good way to look competent, posting something like this. Countdown until edit or takedown...

eshyong 12y ago
Wait, I'm confused. From the following line: https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core_engine_benchmark.js#L228 https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... Doesn't this line calculate the amount of time it takes to compute a single task? (elapsed time / number of runs = time per run) Doesn't this mean that JXcore is actually faster, since the number would be smaller with more runs?
- moisy 12y ago
  numbers seem less important considering the run times.
- bbllee 12y ago
  // Suites of benchmarks consist of a name and the set of benchmarks in // addition to the reference timing that the final score will be based // on. This way, all scores are relative to a reference run and higher // scores implies better performance. https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core_engine_benchmark.js#L66-L75 https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... For complete clarity, see also the lines https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core_engine_benchmark.js#L182-L183 https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... The score is (arbitrary reference constant) / (geometric mean of runtime). Bad performance ==> longer runtime ==> lower scores.

by bbllee 12y ago

eshyong 12y ago

Wait, I'm confused. From the following line: https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core_engine_benchmark.js#L228 https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... Doesn't this line calculate the amount of time it takes to compute a single task? (elapsed time / number of runs = time per run) Doesn't this mean that JXcore is actually faster, since the number would be smaller with more runs?

moisy 12y ago
numbers seem less important considering the run times.
bbllee 12y ago
// Suites of benchmarks consist of a name and the set of benchmarks in // addition to the reference timing that the final score will be based // on. This way, all scores are relative to a reference run and higher // scores implies better performance. https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core_engine_benchmark.js#L66-L75 https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... For complete clarity, see also the lines https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core_engine_benchmark.js#L182-L183 https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... The score is (arbitrary reference constant) / (geometric mean of runtime). Bad performance ==> longer runtime ==> lower scores.