Suggestion: Look into porting to Rust and using Tokio

[brucod]

Alex Crichton, from the Rust Core team, gave a great presentation on Concurrency in Rust with Async I/O using Tokio at code::dive 2017. As soon as I watched your Deno talk, I thought about his. It is long, but I highly recommend watching it.

From his talk: Using a simple hello world benchmark, they achieved almost 2mil req/sec - nearly 250k more than the next best implementation and 500k more than Go's fasthttp. Out of the box, Tokio supports 'TCP, UDP, Unix sockets, Named pipes, processes, signals, http, http2, web sockets, ...'

Some observations (Some may be wrong and definitely missing some 😃):

• Mio crate handles all the OS async abstractions for you for each major platform bundled into Tokio. No re-inventing the wheel.
• They don't use callbacks like Node but futures and task-scheduling.
• Actual threadsafe concurrent/multi-threaded async operations and servers. See Rayon as well
• Async/await Rust syntax that might map well to V8/JS's async/await implementation.
• Rust is already poised for WebAssembly. Writing Deno in Rust, developers won't have to know Go as well.
• Rust is young but growing - voted most loved language for third year in a row Stack Overflow's yearly survey
• Tokio's thoughtful design appears to lend to extensible use cases and crates.
• Tokio is written and supported by members of the Rust Core team.
• No garbage collection

Thanks for the cool, new project and your time

Edit: Forgot to include no GC

[arjunyel]

One block is Deno uses Protobufs for communication but they are not officially supported in Rust, There are third party libraries tho.

I think Rust would be a great fit, it seems Mozilla is putting a lot of work into WebAssembly 😄

[FrankFang]

https://github.com/ry/deno/issues/208#issuecomment-395739171
https://github.com/ry/deno/pull/209#issuecomment-395985554

[fluxxu]

I am a huge Rust fan, and I agree with the advantages you listed. But I don't think now is the best time for deno to invest to Futures/Tokio, considering

• Future has some difficult ergonomics problems now.
• Future and task system were just merged into std 2 days ago.
  Add Future and task system to the standard library rust-lang/rust#51263 (comment)
• async/await is not implemented now. I know the design work is almost done. And there is a prototype futures-await. But it takes time to settle all the details.
• Rust 2018 is expected to release in September. I am not saying it will break everything, but some major refactoring is foreseeable.

These are not deal breakers, and Rust core team is resolving them quickly. It's just not sensible to add these complexities to deno now, which itself an experimental project.
I think the better approach is to implement low-level modules using C++ now, and later port them to Rust after Rust's async io story settled.

[matiasinsaurralde]

I've been playing around with Rust and wrote this wrapper of libv8worker2, might not be useful but I wanted to explore some of the language capabilities for this: https://github.com/matiasinsaurralde/rust-v8worker2

The biggest problem is not going to be making the native part of deno fast - there are tons of fast native servers. Where everything is going to be determined is how lightweight the JS wrapper of this server will be. Clearly Node.js completely failed at this, even though their native components are not all that slow.

A fast native server pushing 5 million pipelined hello world HTTP requests per second can be completely butchered by an inefficient JS wrapper, capping out at only a few thousand req/sec (see Node.js) while a well thought out wrapper with minimal amount of dynamic JS resources per request may very well keep up to 20% of the native performance, landing at 1 million req/sec from within JS (see "uws" for Node.js and Japronto for Python cases). The JS wrapping is by far the most perf. sensitive component.

What I would like to see as a highly prioritized item on the agenda is a benchmark of Deno as is, with Golang. Because if Deno cannot properly retain even the perf. of the built-in Golang HTTP module then it will make no difference at all spending a lot of time rewriting the native parts in Rust. We really need to see a benchmark of Deno in action as soon as possible. This should be priority nr. 1 before every other decision really. Otherwise we end up with the same story of Node.js: an overly optimized HTTP parser written in C that does 50 billion req/sec on paper but when put into Node.js caps out at barely 18k req/sec.

[matiasinsaurralde]

@alexhultman I've been running a few benchmarks on deno with Go and also extended the profiling options in order to make it easier to find potential bottlenecks (#193). The Go profiling tools provide a great overview and you can visualize stuff like this:

I've been working with Go interop for around two years, integrating Python, Lua and other runtimes with a HTTP server (actually an API gateway that people use to handle many requests) and I would say that the overhead of cgo calls is pretty big.
I think that the @ry minimal V8 bindings are pretty good and helps on keeping this overhead as low as possible, at the same time I've been hacking around Rust (and also learning it!) and recently ended up porting this component. I've also started to hack on a minimal deno port that uses std::sync::mpsc (have also tried crossbeam, really exciting stuff) in order to be able to benchmark and potentially compare both implementations. From my Rust experiments it seems that interop is lighter here and this could represent a big performance gain.
You may also find these benchmarks interesting, of course this is experimental and I'm sure there are many ways to optimize this.

@matiasinsaurralde Your PR displays exactly what I feared: Deno will end up clogging up at the JS wrapper performing with horrible throughput. Not even beating Node.js, swapping to Tokio is completely pointless until that wrapper is fixed. The entire Deno project is completely pointless if it's just going to be a worse performing copy of Node.js.

[ry]

@alexhultman Removing Go is to avoid a double GC - which I think everyone can appreciate. And we're experimenting with interfaces - first pass implementations like the HTTP patch let us test. No one is claiming any release or interface commitment.

[matiasinsaurralde]

In case anyone is interested in hacking around, I've pushed a few tweaks for rust-v8worker2 and a limited implementation of Deno code in Rust here (currently you can boot up the runtime and execute a program, only readFileSync is implemented at the moment) 👍

[brandonros]

How do the HTTP benchmarks look when using reno? @matiasinsaurralde

[matiasinsaurralde]

@brandonros I haven't implemented the HTTP module yet, there are many options for this. I've been doing some quick benchmarks with this system call readFileSync (calling this 5000 times).

1. Running the Deno version that uses Go:

% ./deno readfile.ts 
elapsed =  190

2. Running reno using a debug build:

% ./target/debug/reno readfile.ts 
elapsed =  250

3. Running reno using a release build:

% ./target/release/reno readfile.ts 
elapsed =  140

4. NodeJS:

% node readfile_node.js 
elapsed =  77

The main advantage of Rust in this scenario is that we can interact directly with the C data structures, etc.
I've been trying to measure the overhead of using Protocol Buffers as described in #269 and started to migrate our Protocol Buffers definition to Cap'n Proto, implemented the Rust side of it but got stuck trying to parse these messages on the V8 side, found issues with the Cap'n Proto TS library that require some serious debugging.

[brandonros]

@matiasinsaurralde If you had to estimate, do you have faith that switching to Cap'n Proto will bring the elapsed time down from 140, close to Node's 77?

For perspective, it might make sense to show how long the pure C/pure Rust version of the same benchmark would take?

Much like @alexhultman, I'm struggling to see the benefit of running a message-passing layer on top of V8, given the performance. How does node.js currently solve this issue?

For perspective, it might make sense to show how long the pure C/pure Rust version of the same benchmark would take?

For HTTP Deno would currently be about 13x off.

[ssokolow]

Running reno using a releasebuild:

% ./target/release/reno readfile.ts 
elapsed =  140

NodeJS:

% node readfile_node.js 
elapsed =  77

NPM encountered something similar to this during a reliability-oriented rewrite of one of their components and wound up discovering that a surprising amount of the difference was down to how much optimization effort had been put into Node.js in areas you'd underestimate the impact of, like default buffer sizes.