Hacker News new | ask | show | jobs
R3 bindings for Node.js (github.com)
36 points by pedro93 4352 days ago
5 comments

As an additional datapoint, Haskell's Snap Framework implements O(log n) routing like this: https://github.com/snapframework/snap-core/blob/master/src/S...
I wrote something similar (trie based routing) in native js, using ES6 Map and WeakMap: https://github.com/oconnore/tree-router
Can someone point me to the "high performance" aspect of this router? Any benchmarks or documentation supporting this?
It pre-compiles routes to a prefix trie [0], which allows it to match any route in one run by walking down the tree rather than trying each route from scratch. Nginx uses the same strategy for static routes.

————

0. https://en.wikipedia.org/wiki/Trie

R3 does look fast, but there's a cost to crossing the JS -> C barrier. It's almost certainly possible to beat it using the same algorithm written in pure JS.
the routes are pre-compiled, so I think it only requires one calling conversion from js to c++ when dispatching routes.
Finding a match in a tree structure is asymptotically O(log n), finding a match in a list is O(n). This router is also written in C.

There is a benchmark in the README comparing R3 to the Rails router and also to a replacement Rails router that I wrote for non-performance related reasons.

It should be noted that usually only a tiny proportion of the time taken to respond to a request is spent in route recognition. YMMV.

It's a binding library of r3, you may check the benchmark from r3 project:

https://github.com/c9s/r3#performance

I don't know for node but FFI calls usually have an overhead. Depending on the complexity of the routes it might be faster to use a pure version.
Is Express.js support on the roadmap or currently feasible in some way (besides completely forking Express.js) ?
there is also a binding library for Go

https://github.com/freehaha/go-r3