Echo: A fast HTTP router and micro framework in Go

I don&#x27;t understand why people keep reinventing routers even though routing doesn&#x27;t take much time anyways, especially in a compiled language like Go.<p>Most APIs seems to respond within 20 to 200ms. Even if you take 1ms to route stuff, what&#x27;s the point in spending so much time in trying to optimize routing instead of SQL queries, cache layers or developer productivity with a nice ORM ? Trying to squeeze nanoseconds out seems pointless to me at the moment, especially since newcomers to Go end up seeing 20 different routers and might not know where to start.<p>I&#x27;m genuinely wondering.

I didn&#x27;t want to release this today... but there we go. Gin will also be a zero allocation http router.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;gin-gonic&#x2F;gin&#x2F;issues&#x2F;249" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gin-gonic&#x2F;gin&#x2F;issues&#x2F;249</a>

Interesting approach. I guess there are use cases where the small number of allocs of some of the other routers is enough to cause problems.<p>I&#x27;ll definitely stick to httprouter as my default starting point, though. The params interface is much nicer, and it&#x27;s pretty damn good with performance and allocation count: <a href="https:&#x2F;&#x2F;github.com&#x2F;julienschmidt&#x2F;httprouter" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;julienschmidt&#x2F;httprouter</a>

It is interesting and surprising how many allocations per request other frameworks do, from 100s to 10000s.<p>They&#x27;re sort of cheating by having a pool, and sort of punting with things like &quot;&#x2F;&#x2F; MaxParam sets the maximum allowed path parameters. Default is 5...&quot;

I&#x27;m curious what they did different than httprouter to remove the allocations, or if they trick the benchmark tool by reusing memory with a pool.

It would have been nice if the library conformed to http.Handler. That has nothing to do with routing yet whenever a new router comes out, it&#x27;s non-idiomatic. I&#x27;ll take free performance anyday but not if I have to rewrite code.

I&#x27;m curious as to why they chose to use a separate echo.Context. Why not create a type with an embedded io.ReaderCloser and a map[string]interface{}. Then replace the req.Body (it&#x27;s a io.ReaderCloser) with the custom type. You could then write methods that take a http.Request to add&#x2F;delete&#x2F;modify the piggy backing context field. No need to have a Context type in your handlers.

It appears to be storing routes in a tree structure allocated via struct literals in router setup. I&#x27;m imagining that if performance is relying on them always being on the stack, that would be an implementation detail of the Go runtime and may change.<p>Looks like a decent implementation, but aesthetically I dislike monolithic &quot;frameworks&quot; (eg: &quot;echo.New()&quot;). The &quot;Go way&quot; is to write small composable libraries, not opaque frameworks. Gorilla would have been a good model to draw inspiration from.

What do you mean by zero memory allocation? The title seems contradictory. You have to allocate at least some memory for a program to run.<p>Do you mean it doesn&#x27;t allocate any memory per request, it just uses pre allocated memory?