Hacker News Reader

Comment by offtop5 | Hacker News Reader

Does this offer a speed increase vs running the the code directly using $ deno test.js ( not sure what the exact command is )

View on HN

Not really (at least yet, I think). This simply bundles the Deno binary and the script (I think the pre-compiled, as in TypeScript -> JavaScript, then possibly as pre-compiled AST). This is why the output binary size is the original Deno binary + the script size (roughly).

So it's functionally equivalent to running using deno test.js

Correct. We are currently working on reducing size for these `deno compile` binaries. From preliminary testing we think we can reduce size by around 60%.

Regarding speed, we are investigating V8 snapshotting of the user code, which would give it a great boost in startup time. Actual runtime performance would be the same.

Would it be theoretically possible, to end up using this as sort of a scripting language for rust or whatever. I'm imagining Deno somehow getting complied down to Rust and then running at Rust speed.

I basically want low level performance without writing in a difficult language

No this is not possible. JS is too dynamic for that to work.

Not really, I think. Startup of a "hello world" seems to be 5ms faster on my Windows machine: https://gist.github.com/MarkTiedemann/c2f4013c3a60bb28df5005...

What's up with the page faults in the timing details?

Not much. Similar to the context switches column, a couple of thousand page faults are quite normal for a quickly executed Windows program. For comparison, listing all running processes, you'll hit ~1-10k page faults (see timeit benchmark results at the top of the readme: https://github.com/MarkTiedemann/fastlist).

No, there's not really any optimization. It's more of a bundling convenience. It still includes V8.

Reply on news.ycombinator.com