Update Hono (bun) impl. for 20% speed boost
redbar0n opened this issue · 9 comments
For example, Hono on Bun looks like it performs badly. But just go to src/bun/hono.ts and change the export to export default { ...app, host: '127.0.0.1' } (instead of export default app) for an instant 20% speed boost that puts it right up, near the top.
according to hattipjs/hattip#114 (comment)
Benchmarks should use 127.0.0.1 (IPv4) instead of the name 'localhost', due to potential IPv6 overhead or conflict: don't use localhost (intermediate) anthony explains (4 min).
I agree with the benchmark of 127.0.0.1 benchmark part, but disagree with the hattip part:
For example, Hono on Bun looks like it performs badly. But just go to src/bun/hono.ts and change the export to export default { ...app, host: '127.0.0.1' } (instead of export default app) for an instant 20% speed boost that puts it right up, near the top.
Basically, in any server more complex than hello world app, you are likely going to implemented either reverse proxy, micro-service or load balancing for multiple endpoint, eg. staging:
- api.stuff.dev
- staging.api.stuff.dev
- internal.api.stuff.dev
Setting the host ahead of time rejects all of the above implementation.
Additionally, the 20% speed boost is not only limited to Hono, but Elysia, Stric, Vixeny and most frameworks are going to benefit the speed boost as well since the hostname is known ahead of time, we can just omit the hostname entirely.
But we assume that the API staging or load balancing / reverse proxy will be implemented, that optimization doesn't match the real use case.
Setting the host ahead of time rejects all of the above implementation.
That was my point actually. When I ran the tests a couple of months ago, some of the tested frameworks assumed a certain host name (vixeny's hasName, stricjs's base etc.) which gave them an unfair advantage. Setting the host gives the same advantage to Hono. You can (and should) also go about the other way and disable those optimizations in those frameworks.
Didn't realize Stric and Vixen hardcode basename.
Alright, going to remove the basename and rerun the benchmark right now, thanks.
@SaltyAom Would be awesome if you could update the README with the new bench results. It currently says Tested on 18 Mar 2024 19:30 (GMT+7)
Setting the host ahead of time rejects all of the above implementation.
That was my point actually. When I ran the tests a couple of months ago, some of the tested frameworks assumed a certain host name (vixeny's
hasName, stricjs'sbaseetc.) which gave them an unfair advantage. Setting the host gives the same advantage to Hono. You can (and should) also go about the other way and disable those optimizations in those frameworks.
Hello, I was looking at issues and I stumble upon this conversation, the reason why I added hasName (base.bind in the beta version) is for vixeny-create where I use it as a default point of reference, I'm removing it and I will talk to Reve to see if he can do the same.
It should be fixed by the next benchmark sorry for the trouble xd.