Compare bootstrap speed with Node.js about deno HOT 18 CLOSED

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

from deno.

@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

from deno.

@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.

from deno.

@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;

from deno.

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.

from deno.

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 : )

from deno.

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

from deno.

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.

from deno.

@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.

from deno.

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.

from deno.

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.

from deno.

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

from deno.

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

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

from deno.

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

from deno.

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.

from deno.

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

from deno.

@thysultan make sense, i thought about that too.

from deno.

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

from deno.