You know, if can change code without overhead to ends of the pipeline, using the language & library of my choice, I’d do this too. For many of us this isn’t always the case.
It’s faster for 3 digits and more. 3 digits is not galactic scale. Otoh, if over half of your numbers are single digits, it will lose to other implementations. I think that is more often the case that we’d like it to be.
What you can do in C# today is convert any unsafe pointer to Span whenever you get your hands on it, and pass around slices. You can still drop down to ‘fixed’ when it turns out you need it for performance.
I could say that the perf difference between spans and unsafe pointers in most cases is just zero, if not in favor of spans at times due to the optimized helper methods or just better code generation. Add the safety benefits to the mix, and it's a no brainer. So, unsafe pointers may not have an edge for performance anymore. They might have other uses cases of course: interop, etc.
With fixed you do pinning on GC memory, which can have a negative performance effect. You can also do unchecked pointer arithmetics on references with the Unsafe class, which avoids that. A lot of the methods of Span use that internally.
The way I understood the 80% is that is the margin on the actual product. 36% is what remains after the “investments” in moonshot projects nobody asked for.
I’ve learned this lesson over the years. It is quite common that users make a screenshot of the error with their phone, and send it on to support with hardly any details. The fact that errors become recognizably different is also an improvement: the user and support staffer can recognize recurring errors, and notice patterns.
In a perfect world, there would be a stable version of chrome, that would get fixes, but would crucially not get the new features that introduce new vulnerabilities. Not a fun job, I know, but with today’s coding agents it wouldn’t even be an unreasonable ask.
reply