Deno: Question: Is there a difference in execution time between node and deno?

Created on 7 May 2020  路  5Comments  路  Source: denoland/deno

Hi!
I recently perused deno's benchmark page and first off it is amazing! It gives a birds eye view on the progress of deno. There were certain benchmarks I found particularly useful (like hyper being used as an upper bound on the requests per second benchmarks.

For the execution time benchmark I see both cold and warm starts, but I assume these are all using the deno runtime. So, I wanted to ask, is there a difference in pure execution time between the two? Does it just drop down to the v8 engine so performance is identical? Is it useful to add nodejs execution time as a "lower bound"?

benchmarks

Most helpful comment

I created test on array.shift and was surprised that deno 1.0.0-rc3 was more than twice as fast as node 14.0.0 at completing the test. What accounts for such a large difference performance?

There are several factors, but v8 performance is sometimes a dark art. The most logical reason would be that all Deno modules are loaded as ES Modules... That means they are always run in strict mode. Did you use "use strict"; under Node.js? You have to be explicit about that with CommonJS under Node.js. There could be a couple of other lower level reasons as well, as we eliminated __proto__ form Object.prototype, which might have a small lookup improvement.

Also, Deno is on v8 8.4.3.. I believe Node.js 14 is on 8.1, so there could be any number of other contributing factors.

All 5 comments

Thanks - the benchmark page has been very useful in making decisions on large refactors.

For the execution time benchmark we're primarily concerned with how long we spend in the TypeScript compiler - it's by far the biggest bottleneck in Deno - these are the "cold start" benchmarks. When we have JS and are executing code, that's just V8 - we startup faster than Node last time I checked - but since the startup time is on the order of milliseconds, it's pretty much already optimal. That said, I'd be happy to take a patch adding a Node baseline in there.

@ry I was trying some benchmarks in order to include Deno in the benchmark game (See: Should JavaScript section be split by runtimes?), and I discovered that some benchmarks run lower under Deno vs Node. Since the measures were taken also with console.time i'm confused on why the lower performance as you expressed it yourself, they should be having both the same following the V8 argument.

Thanks for the clarification! I will see if I have some free time this weekend to contribute a node benchmark

@ry : Like @andykais and @Soremwar , I too am surprised at how deno can be so much faster than node on tasks that seem to rely upon the same javascript engine.

I created test on array.shift and was surprised that deno 1.0.0-rc3 was more than twice as fast as node 14.0.0 at completing the test. What accounts for such a large difference in performance?

I created test on array.shift and was surprised that deno 1.0.0-rc3 was more than twice as fast as node 14.0.0 at completing the test. What accounts for such a large difference performance?

There are several factors, but v8 performance is sometimes a dark art. The most logical reason would be that all Deno modules are loaded as ES Modules... That means they are always run in strict mode. Did you use "use strict"; under Node.js? You have to be explicit about that with CommonJS under Node.js. There could be a couple of other lower level reasons as well, as we eliminated __proto__ form Object.prototype, which might have a small lookup improvement.

Also, Deno is on v8 8.4.3.. I believe Node.js 14 is on 8.1, so there could be any number of other contributing factors.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

CruxCv picture CruxCv  路  3Comments

ry picture ry  路  3Comments

xueqingxiao picture xueqingxiao  路  3Comments

benjamingr picture benjamingr  路  3Comments

kyeotic picture kyeotic  路  3Comments