11 ms·

I don't understand why people keep reinventing routers even though routing doesn't take much time anyways, especially in a compiled language like Go. Most APIs

by conradk 12y ago

I don't understand why people keep reinventing routers even though routing doesn't take much time anyways, especially in a compiled language like Go. Most APIs seems to respond within 20 to 200ms. Even if you take 1ms to route stuff, what'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. I'm genuinely wondering.

jsprogrammer 12y ago
It's satisfying to roll your own?
- peterwwillis 12y ago
  Basically. Every kind of program known to mankind will be implemented if a language remains popular long enough. There are web servers written in awk, but nobody cares because awk isn't compumateguistically threatening to them. I mean, you could even make a web server/router/framework out of Javascript, but what kind of lunatic would do that?
gkya 12y ago
A router is rather easy to create, so I reckon this sort of easy projects are appealing to people as beginner projects and pet projects, so they implement them and put them on the internet just for kudos or karmas or for merely showin' off to potential employers.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
codexon 12y ago
20ms is not fast enough for requests served from memory. Many routing implementations are awful, comparing the URL to every single entry instead of using a trie can add up.
steveklabnik 12y ago
http://permalink.gmane.org/gmane.comp.db.sqlite.general/90549 http://permalink.gmane.org/gmane.comp.db.sqlite.general/9054... > The latest SQLite 3.8.7 alpha version (available on the download page > http://www.sqlite.org/download.html) is 50% faster than the 3.7.17 release > from 16 months ago. That is to say, it does 50% more work using the same > number of CPU cycles. > > The 50% faster number above is not about better query plans. This is 50% > faster at the low-level grunt work of moving bits on and off disk and > search b-trees. We have achieved this by incorporating hundreds of > micro-optimizations. Each micro-optimization might improve the performance > by as little as 0.05%. If we get one that improves performance by 0.25%, > that is considered a huge win. Each of these optimizations is unmeasurable > on a real-world system (we have to use cachegrind to get repeatable > run-times) but if you do enough of them, they add up.
count 12y ago
Shaving 1ms off of every single request can have a larger overall impact than optimizing queries/etc. that are not used for every. single. request. I'm not saying I agree, but just one possible answer.
rodgerd 12y ago
It's particularly jarring for me given that whenever there's a post about someone moving away from Amazon and seeing significant performance and/or cost benefits the HN zeitgeist tends to be rubbishing it as too much work for the benefit, but endlessly re-solving the same problems over and over in software for much smaller gains tends to be wildly applauded.
- pekk 12y ago
  If 80% of posters on a thread about diets say vegetarian is healthier, and 80% of posters on a thread about fun recommend riding a motorcycle, it doesn't follow that there is a single HN zeitgeist saying both things. A simpler explanation is that there are two groups which speak up in different situations. Those groups don't necessarily overlap much.
frowaway001 12y ago
Most other things (like the ones you mentioned) require a level of expressiveness that Go lacks. SQL: Pointless without Generics. Cache layer: Pointless without Generics. ORM: Pointless even with Generics.
zaroth 12y ago
At first I came here thinking the same thing. Then after looking at the benchmarks in README I decided it's a worthy attempt at refining the craft and eliminating the cruft of what else has come before. It's no 100 mile mountain race, but it is more interesting than just some random HelloWorld router.
mbell 12y ago
> Most APIs seems to respond within 20 to 200ms. Many of our internal services respond in < 5ms while handling thousands of requests per second. 1ms of routing a big deal.
deleted 12y ago
[deleted]
ithkuil 12y ago
It's not only about time, it's about GC pauses. If you allocate hundreds of KB on each request (even simple stuff like health checks, or frequently polls for "is there anything ready yet" (in memory not db access etc), you will have a higher GC cost, and possibly having long GC pauses. Go 1.5 is going to improve on the GC pauses, but another way of improving it is to just create garbage (by reusing memory). Go doesn't have manual heap allocation and free, but you can easily achieve manual memory management by simple means like handling your own pools.

by conradk 12y ago

jsprogrammer 12y ago

It's satisfying to roll your own?

peterwwillis 12y ago
Basically. Every kind of program known to mankind will be implemented if a language remains popular long enough. There are web servers written in awk, but nobody cares because awk isn't compumateguistically threatening to them. I mean, you could even make a web server/router/framework out of Javascript, but what kind of lunatic would do that?

gkya 12y ago

A router is rather easy to create, so I reckon this sort of easy projects are appealing to people as beginner projects and pet projects, so they implement them and put them on the internet just for kudos or karmas or for merely showin' off to potential employers.

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

codexon 12y ago

20ms is not fast enough for requests served from memory. Many routing implementations are awful, comparing the URL to every single entry instead of using a trie can add up.

steveklabnik 12y ago

http://permalink.gmane.org/gmane.comp.db.sqlite.general/90549 http://permalink.gmane.org/gmane.comp.db.sqlite.general/9054... > The latest SQLite 3.8.7 alpha version (available on the download page > http://www.sqlite.org/download.html) is 50% faster than the 3.7.17 release > from 16 months ago. That is to say, it does 50% more work using the same > number of CPU cycles. > > The 50% faster number above is not about better query plans. This is 50% > faster at the low-level grunt work of moving bits on and off disk and > search b-trees. We have achieved this by incorporating hundreds of > micro-optimizations. Each micro-optimization might improve the performance > by as little as 0.05%. If we get one that improves performance by 0.25%, > that is considered a huge win. Each of these optimizations is unmeasurable > on a real-world system (we have to use cachegrind to get repeatable > run-times) but if you do enough of them, they add up.

count 12y ago

Shaving 1ms off of every single request can have a larger overall impact than optimizing queries/etc. that are not used for every. single. request. I'm not saying I agree, but just one possible answer.

rodgerd 12y ago

It's particularly jarring for me given that whenever there's a post about someone moving away from Amazon and seeing significant performance and/or cost benefits the HN zeitgeist tends to be rubbishing it as too much work for the benefit, but endlessly re-solving the same problems over and over in software for much smaller gains tends to be wildly applauded.

pekk 12y ago
If 80% of posters on a thread about diets say vegetarian is healthier, and 80% of posters on a thread about fun recommend riding a motorcycle, it doesn't follow that there is a single HN zeitgeist saying both things. A simpler explanation is that there are two groups which speak up in different situations. Those groups don't necessarily overlap much.

frowaway001 12y ago

Most other things (like the ones you mentioned) require a level of expressiveness that Go lacks. SQL: Pointless without Generics. Cache layer: Pointless without Generics. ORM: Pointless even with Generics.

zaroth 12y ago

At first I came here thinking the same thing. Then after looking at the benchmarks in README I decided it's a worthy attempt at refining the craft and eliminating the cruft of what else has come before. It's no 100 mile mountain race, but it is more interesting than just some random HelloWorld router.

mbell 12y ago

> Most APIs seems to respond within 20 to 200ms. Many of our internal services respond in < 5ms while handling thousands of requests per second. 1ms of routing a big deal.

deleted 12y ago

[deleted]

ithkuil 12y ago

It's not only about time, it's about GC pauses. If you allocate hundreds of KB on each request (even simple stuff like health checks, or frequently polls for "is there anything ready yet" (in memory not db access etc), you will have a higher GC cost, and possibly having long GC pauses. Go 1.5 is going to improve on the GC pauses, but another way of improving it is to just create garbage (by reusing memory). Go doesn't have manual heap allocation and free, but you can easily achieve manual memory management by simple means like handling your own pools.