Earlier quoted context omitted.
Why is a trie obviously better then a hash map?
Fixed lookup time. A trie (aka radix tree) 3 levels deep with 1 million entries has the same lookup time as a 3 level deep trie with 5 entries.
Mux – A lightweight, fast HTTP request router for Go
41–50 of 80 posts
Re: Mux – A lightweight, fast HTTP request router for Go
#42Earlier quoted context omitted.
Looks like it uses regexp... There isn't any benchmark code as one would expect when making a claim that it's "fast".
Go regexps are slow ( https://goo.gl/r0K2xw ), the problem is not regexps but Go's implementation of regexps. So let's not blame regexps when regexps aren't the problem. Because by that logic, people shouldn't use the sort package as well ...
Re: Mux – A lightweight, fast HTTP request router for Go
#43I don't usually say this but - isn't this a poor choice of name? Gorilla framework's Mux [0] has been around awhile and is quite popular for routing in Go. [0] https://github.com/gorilla/mux
That's why we have namespaces. There's gorilla/mux and now there's donutloop/mux.
Re: Mux – A lightweight, fast HTTP request router for Go
#44Earlier quoted context omitted.
Looks like it uses regexp... There isn't any benchmark code as one would expect when making a claim that it's "fast".
Regexp definitely isn't something you'd want to be using if you're primary goal is speed. When running tight loops in string parsing I've found using string splitting and then cycling through the range of indices in a slice was several times faster than Regexp matching. Obviously performance difference will vary depending on the expression and application but that was enough to convince me to think twice about future…
Re: Mux – A lightweight, fast HTTP request router for Go
#45My favourite current HTTP request router is https://github.com/pressly/chi The list of those using it in production includes: - Pressly - Cloudflare - Heroku - 99designs - Origami - IT Jobs Watch - CrowdRiff At Cloudflare it's our default router for internal APIs, which are all written in Go. (and yes it uses a trie)
Do you know how it stacks up to httprouter for example? We can run benchmarks all day but it would be cool if you happened to have some real production statistics, by any change?
/users/:id
/users/create
Seems like a common use case.Re: Mux – A lightweight, fast HTTP request router for Go
#46I don't usually say this but - isn't this a poor choice of name? Gorilla framework's Mux [0] has been around awhile and is quite popular for routing in Go. [0] https://github.com/gorilla/mux
I typically read the HN comments before clicking on a link, and I actually thought this _was_ a post about gorilla/mux until I got to your comment.
Re: Mux – A lightweight, fast HTTP request router for Go
#47Does it use a trie? If not, it probably should. Here's a wonderful talk on using that datastructure (with go) for the gov uk url router: https://gdstechnology.blog.gov.uk/2013/12/05/building-a-new-... The Vulcan proxy from Mailgun does the same thing: http://vulcand.github.io/proxy.html#route It looks like it doesn't, so existing open source golang url routers will perform much better, contrary to this post. The one…
Why is a trie obviously better then a hash map?
Re: Mux – A lightweight, fast HTTP request router for Go
#48Earlier quoted context omitted.
Go regexps are slow ( https://goo.gl/r0K2xw ), the problem is not regexps but Go's implementation of regexps. So let's not blame regexps when regexps aren't the problem. Because by that logic, people shouldn't use the sort package as well ...
Regexes are the problem, because they're simply the wrong tool for the job.
for what job? Extracting route variables from paths ?they are the right tool for the job, only in the Go community they are deemed "wrong tool for the job". Your statement embodies everything that is wrong with the Go community. Instead of finding a solution to a problem you guys spend your time shifting the blame on "bad practices".
Re: Mux – A lightweight, fast HTTP request router for Go
#49Earlier quoted context omitted.
Regexes are the problem, because they're simply the wrong tool for the job.
> Regexes are the problem, because they're simply the wrong tool for the job. for what job? Extracting route variables from paths ?they are the right tool for the job, only in the Go community they are deemed "wrong tool for the job". Your statement embodies everything that is wrong with the Go community. Instead of finding a solution to a problem you guys spend your time shifting the blame on "bad practices".
Re: Mux – A lightweight, fast HTTP request router for Go
#50I don't usually say this but - isn't this a poor choice of name? Gorilla framework's Mux [0] has been around awhile and is quite popular for routing in Go. [0] https://github.com/gorilla/mux