Fastest router: allocation free on matching and in retrieve parameters

Hi folks, i like to introduce you to this router library that i developed, on my benchmarks it’s performs better than all routers that i tested, this implementation is 100% zero allocations, doesn’t matter how many parameters you have in you pattern.

Another zero allocations router, with this pace, the routing will soon be no-op, even applications with routers will be faster than ones without.

No seriously, too many “zero allocations” routers started popping up, people need to understand that the bottleneck is hardly in the router.

Just my two gophers


If there is a place where we can optimize is always better, and all the routers that i saw they are allocating when the pattern has one or more parameters.


I said this in response to another library making these claims, and I think it bears re-posting:

The problem with those (infamous) router benchmarks is that routing performance is a tiny slice of your total request-response time, and never the bottleneck.

The moment you read something from the request, you eclipse the time spent routing. Communicate with a database? Order-of-magnitude more! You would likely see a better performance gain by initializing slices to the size your DB result count (reducing slice copies) than by changing routers.

You should also detail why you are faster: many zero-allocation routers in Go have been unsafe as they presume static parameters, or re-use parameters across requests (read: optimizing for benchmarks).

Talk about a great API, http.Handler compatibility, context.Context support, middleware chains - etc (if your library has those things) — they are infinitely more useful than shaving an alloc off a request.


@gngeorgiev @elithrar i agree in parts, we all know that Go is a garbage collected language and less garbage means less work per GC cycle.

About why it’s fast: first because the library use a radix tree, second, because when retrieves a parameter will only extract the string slice from the provided URL string, works more less like Tag.Get method in the reflect package.


Rather than competing on being the fastest possible router, I’d like to see someone put together a fast router that actually implements routing based on Content-Type so I don’t have to do it manually.

People do it because it might be the easiest portion of a web app to re-implement in Go.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.