Comments (2)
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.
from zap.
fixed in commit d7946ec
from zap.
Related Issues (20)
- Build error HOT 2
- Using zap with BTRFS on Linux 6.5.0 causes a package hash mismatch HOT 6
- Unable to build "run-hello" with current zig master (0.12.0-dev.934+a241cf90d) HOT 2
- build.zig.zon requires path field HOT 3
- zig errors on variables that need to be treated as const instead of var HOT 1
- Failure To Build: panic: unable to find artifact 'facil.io' HOT 2
- Build error using TLS HOT 5
- Re-add the -Dopenssl option to zap build HOT 3
- TLS - Random requests stalling & occasional segfault [raspi aarch64] HOT 19
- Exposé API for fetching MIME type for given extension HOT 4
- Add `std.io.Writer` and `std.io.Reader` support for `zap.SimpleRequest` HOT 4
- Represent request method as enum instead of string HOT 1
- Zap won't compile on Microsoft Windows. HOT 2
- Zig as a starter HOT 13
- Failure to compile facil.io : unable to build C object: clang exited with code 1 HOT 2
- RequestHandler doesn't work with multiple invocations where self is the same type HOT 3
- hot-code reloading or swapping HOT 1
- Segfault after 60 seconds of inactivity HOT 12
- Add examples/tests for getHeaderCommon
- Maximum number of concurrent requests per Zap process HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zap.