(Pre-disclaimer: I think it's great that the author spent some time benchmarking and hacking, and I don't mean for this comment to tear down their work, but rather I'm just answering the above question which was also the first thing that came to my mind when I saw this.)

The slowest URL router benchmarked there[1] does 10462.0 runs per second, which is just under 0.1ms per run.

I'm not sure what performance is expected of Rails handlers but the first stackoverflow thread[2] that came up on a simple Google search had twitter doing 600 req/s across 180 instances which comes to 300ms per request.

By that math, the slowest URL router costs 0.033% of the request overhead.

Caveat: 300ms/req is slower than you'd like for an interactive website; real websites may have more complicated routing tables than this benchmark. Counter-caveat: 0.1ms is not enough to matter pretty much anywhere except for the stock market.

[1]: https://github.com/c9s/r3#benchmark

[2]: http://stackoverflow.com/questions/373098/whats-the-average-...

The linked SO answer is fairly dated (2011), Twitter is able to handle bursts of up @140K req/s (with Scala) as of last year[1]

Assume Rails has improved hugely since then, 600 req/s over 180 instances is absolutely abysmal performance O_o

I'd expect Rails to clock in well under 300ms per request now, and looking at Basecamp's site[2], that seems to be the case, impressively snappy page loads (if caching the kitchen sink and not hitting live Rails stack then we'd need to look at a different example, but this site has pretty much optimal load time).

[1] https://blog.twitter.com/2013/new-tweets-per-second-record-a...

[2] https://basecamp.com

In addition, if you were to replace the Rails router with a Ruby trie implementation, it would be even faster. (not that this is encouraged)

I wrote the trie implementation referenced in the benchmarks. I didn't do it for speed, I did it because I couldn't add the router functionality I needed using the existing underlying implementation.

Cool, nice work! I didn't actually look at the benchmark and was just making (perhaps poor) assumptions. I'd imagine it does come with a nice little performance boost though?

Probably not. But it's a very nice library for use in C application with small embedded webserver.

This + libev/libuv + the Node.js HTTP parser makes a nice little application server.

You shouldn't go replacing your Ruby apps with C but there are many cases were embedding Ruby/Python/etc into your C app just doesn't make sense and this is a good way of bringing nice features from those more webby frameworks to C.

It could be if a router/mux is regexp bound and contains a lot of and/or complex patterns.

In that case a C implementation would not help, most languages already use C implementations of their regex engines.

well, just for fun!

Small things add up.

They also add complexity. So the implied question is - is it worth it?

When you use pcre in python or ruby, do you worry about the complexity? pcre and language VMs are also implemented in C/C++.

If we consider complexity before everything, we must use PHP to implement an OS. :-p