Compare bootstrap speed with Node.js

[hefangshi]

➜ tmp echo "console.log('Hello world')" > index.js
➜ tmp time deno index.js
Hello world
deno index.js 1.89s user 0.22s system 138% cpu 1.515 total
➜ tmp time node index.js
Hello world
node index.js 0.08s user 0.03s system 94% cpu 0.109 total

The golang runtime has a huge influence for bootstrap time. How you think about this, seems golang bootstrap time is had to improve.

[qti3e]

it's not related to Golang but V8 and TS, as far as I know, Ryan is going to fix this issue by using V8 snapshots : )

[hefangshi]

I compiled a nodejs without snapshot

./configure --without-snapshot --prefix "$BASE_DIR/"

But the performance didn't drop a lot

time node index.js
Hello world

real	0m0.167s
user	0m0.123s
sys	0m0.042s

[ry]

@hefangshi You've pointed out the issue that bothers me the most. But it's not Golang - it's the TypeScript compiler getting loaded, parsed, and then parsing the input. I believe snapshots will make this much faster ... work is in progress to fix it.

PS if you want to see the speed of Golang startup try time deno -help

[hefangshi]

@ry You are right. I do encounter with some issue of the golang startup performance in other extreme scenario, glad to know that deno don't have this issue.

Although snapshot for ts may reduce typescript load time, but compile time is still hard to improve, maybe deno could provide precomiled running mode for production enviroment in future.

[qti3e]

@hefangshi Deno caches the compiled code (see ~/.deno/cache)

and about production mode you're probably addressing #21 : )

[yorkie]

@qti3e #21 was good to go, however I have another proposal. Deno is absolutely based on TypeScript, such that we actually can compile the source code(TypeScript) into LLVM, and then we have 2 choices:

• if we compile it to WebAssembly, v8 is required, and bootstrap and execution are optimized;
• if we compile it to executable or loadable library, v8 is not required any more, and bootstrap, execution and RSS are optimized both;

[benjamingr]

What about using something that removes the types when run in a production build https://github.com/alangpierce/sucrase?

[ry]

@benjamingr I want only one transpiler compiled in and that is TS. I am confident that V8 snapshotting plus other startup optimizations will reduce startup time substantially. I will know soon and report back.

[SASUKE40]

Is it workable that rewrite TS compiler with golang?
IMHO, it is too heavy to optimize / translate TS on V8 engine. And if we do that, it maybe another Dart, and it makes deno more difficult for spreading in community.
Rewriting TS compiler with golang will optimize the performance in bootstrap period, it could be a easy way.

[kitsonk]

I highly doubt it is workable to rewrite TypeScript in Go. Because it wouldn't only be the language extensions on JavaScript, but a whole JavaScript engine, which is like rewriting the whole of V8 in another language. Even if it were cleanly separable, you would be ignoring the hundreds of people maintaining TypeScript and always be playing catchup. V8 snapshots are the easiest way to find out if they solve the challenge before exploring other solutions.

[tunnckoCore]

I think it's not the golang too, but the TS. I'm pretty curious how will optimize the TS part - it's impossible ;d But let's believe.

[ansarizafar]

Why not just AOT compile javascript/Typescript to a single native binary. Why use V8 runtime?

[kitsonk]

Why not just AOT compile javascript/Typescript to a single native binary. Why use V8 runtime?

You would have to have all code be knowable at run time, including the programme. At that point you are talking about static compilers for JavaScript like EncloseJS or nexe. Both those projects are not deno, both of those projects are already available if that is what you need.

[thysultan]

I think the best of both worlds would be as the goals for file extensions suggest to only run through a TypeScript compiler if it is a .ts extension. That is .js files should strictly be JavaScript and take the fast path.

Edit: Though i think if the core modules are written in '.ts' you would still have to compile that through TypeScript irregardless. So these sound like interesting design decision yet to be finalized depending on the tradeoffs.

[tunnckoCore]

@thysultan make sense, i thought about that too.

[qti3e]

@ry maybe it should be closed by now (?)

[ry]

Yep - snapshots are running now and start up is much better - but we aren’t yet on feature parity with the Go implementation so a bit hard to compare. Closing this and will publish some benchmarks soon

[ry]

Just FYI our benchmarks in this area have improved

> echo "console.log('Hello world')" > hello.js

> deno -v
deno: 0.2.7
v8: 7.2.502.16
typescript: 3.2.1

> time deno hello.js
Hello world

real	0m0.089s
user	0m0.043s
sys	0m0.033s

> node -v
v10.14.2

> time node hello.js
Hello world

real	0m0.680s
user	0m0.097s
sys	0m0.122s