-
Notifications
You must be signed in to change notification settings - Fork 504
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BenchmarkDotNet snippet to compare Span<byte> to raw pointer #370
Conversation
There's a lot more nuance in play than directly comparing them like this 😄 But yes, pointers will generally win in Garnet as there is pinned network buffer on heap which is being reused. |
This was just to check the claim/hope that |
If you already have a pointer, it's of course generally better to stay in the pointer world. And as the team seems clearly comfortable in using them and if they feel intuitive, absolutely it's the choice for Garnet. Especially in the APIs that are not directly exposed to the library consumers. The strength of In Garnet's case, one has to consider the trade-offs of maintaining all the manual parsing logic where we think we can beat BCL. If something we do is measurably faster, why not contribute it upstream for all to benefit (yes, we can always make more assumptions than BCL, so we can be faster) and how to allocate/focus the development efforts. Benchmarking is hard and one can unconsciously write micro-benchmark to give the results they want to see (been there, done that). BenchmarkDotNet tries it best but can't help against the way processors are too smart nowadays. The micro-benchmarked method(s) are going to stay in instruction cache and make for example code that heavily relies on data being L1/L2 cache look, where they would incur a lot more cache-misses in real workloads. And nuances with stupidly smart branch predictors.. etc. I really want to have great benchmarking tooling in Garnet repo to quickly iterate and see real effects of performance changes against different workloads. Something along the lines of ASP.NET's Crank but configurable RESP workloads to see tangible RPS/Memory/Latency/CPU metrics. These don't need to be maximum theoretical special lab-hardware measurement, but something to give indication how much RPS/Latency we lose if, for example, we just used Sorry for the wall of text rambling😅 |
We are in vehement agreement here. In fact, the above BDN seems to suggest that even for this rather contrived case, |
No description provided.