3 ms·
Can someone point me to the "high performance" aspect of this router? Any benchmarks or documentation supporting this?
by aioprisan 12y ago
Can someone point me to the "high performance" aspect of this router? Any benchmarks or documentation supporting this?
- pedro93 12y agoIt's a binding library of r3, you may check the benchmark from r3 project: https://github.com/c9s/r3#performance https://github.com/c9s/r3#performance
- zimbatm 12y agoI 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.
- pygy_ 12y agoIt 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 https://en.wikipedia.org/wiki/Trie
- sjtgraham 12y agoFinding 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.
- phpnode 12y agoR3 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.
- pedro93 12y agothe routes are pre-compiled, so I think it only requires one calling conversion from js to c++ when dispatching routes.