zigzap / zap

blazingly fast backends in zig
MIT License
2.23k stars 75 forks source link

Improve benchmarks #12

Closed Desiders closed 1 year ago

Desiders commented 1 year ago

I see different benchmarks for Rust, Go and Python.

Golang use default http library that asynchronous. Python use synchronous way. Rust use sockets, because this language doesn't have http server in standard library.

I think such benchmarks aren't only useful, but also harmful, because they confuse people.

  1. Since we have a very big difference between the standard libraries of languages, I think it would be more appropriate to compare only the libraries/frameworks of these languages.
  2. Benchmarking of Rust are the most absurd, because this language doesn't have http server in standard library and writing your own and the implementation written in a hundred lines cannot be compared with high-performance analogues in another language, for example GO. In this case, I would prefer to at least use a de-facto standardized HTTP (server) - hyper (https://crates.io/crates/hyper).
renerocksai commented 1 year ago

Please, before you criticize, really look at the benchmarks, discussions, and readme. You'll find both python sanic and rust axum/tokio there, which should also be obvious from the charts in the readme. More on the new additions is in #10 .

While your assessment of the 3 mentioned benchmarks is correct, I cannot take your point about my benchmarks being harmful seriously, nor do I find such exaggerated language serious or necessary. I probably have a different definition of harm.

I think, with axum+tokio I have addressed your main concern of rust looking bad. I literally went by "the book" on rust btw. It's not sth I came up myself.

Here is my comment from zig.news which explains my original motivations, using only on-board resources. Link is in #10 .:


Thanks for your suggestion. I couldn't believe it myself but it is true. "Basic" rust with standard sockets etc. seems to be that slow.

I have not tried tokio or something like that because I wanted it to be an equally unfair contrived comparison. Unfair because I am comparing basically the performance of an optimized C framework with super basic example servers. Contrived because I tested the timing of canned responses.

Have a look at them on GitHub, it's all there. I wanted to compare against a basic python SimpleHttpServer to get an idea for basic python performance. I compared against a standard basic Go implementation to see how zap compares to that. Just to get an idea if zap is 10x slower or if it can keep up.

Why I did it that way?

a) because it was simple

b) because I wanted to compare what you can do with the most simple zap server vs. the most simple python server vs the most simple Go server. If you don't know what to pick, this is maybe how you'd start evaluating. Then with rust, as I said, I literally went by the book. Made sure number of threads etc. is equal to the zap example. It just didn't want to perform that well.

You can find all the source code here.

So far, the question isn't answered why the rust example straight out of the book seems comparably slow - but I guess nobody uses such simple servers in the real world anyway when there's stuff like tokio out there.

I fully understand that there are faster python servers, probably faster Go servers, and certainly extremely fast rust servers out there. So for a fair "which is fastest" comparison, you'd have to check out some fastest server list, build them, build respective meaningful "apps" (as opposed to: contrived) and test against them. Then also build them in the ever evolving zap and see how it performs. I am happy with seeing responses in the us range on my dev PC when testing my frontends against a zap backend. That's the kind of performance I was looking for. I am sure there's faster stuff out there.

renerocksai commented 1 year ago

fixed in commit d7946ec3aff650f7af135b8164d43b1307533897