C# 12 Spread Operator Performance Pitfalls
Вставка
- Опубліковано 7 гру 2023
- Visual Studio gives us lots of hints on how to improve our code. Mostly it's right. Sometimes it's dead wrong.
Source code available at: github.com/JasperKent/Spread-...
Topics include:
- The various ways of creating an empty array
- The performance benefits of using a predefined empty array
- How all ways of creating an empty string work the same way
- Benchmarking of spread operator performance against alternatives
- Bad advice from Visual Studio - Наука та технологія
Thx for sharing your experience. I think C# developers made spread not just for copy full collection items - it is really powerful and cool feature especially if you work with collections. But as I told, not for copying every single element. VS developers should fix this suggestion or we should have some if condition to do ToArray() behind of scene in spread 😄
Awesome channel, very informative videos, thank you for all your effort, you helped me a lot, keep it up please..
thanks for the video! keep up the good work!
Thanks for highlighting the performance concerns. Definitely worth knowing if this sort of thing if tight performance is a constraint for your code.
I disagree that VS offering a slower but clearer version of the code is a bad thing. Clarity trumps performance unless performance is genuinely needed. Developers working with such constraints should have a good understanding of this stuff. IMO in a code file where the VS suggestion is undesirable a pragma should be added the file to turn that suggestion off with a comment from the developer why they have made the choice.
The overwhelming majority of developers will never really need this optimisation. Also later versions of the compiler could identify and optimise this pattern.
I get your point, but I disagree with this populist chant that 'Clarity trumps performance'. They are very equal from my own perspective and it's a good habit to always remember that.
@@anm3037 Well putting aside the "chant" and "populist" nonsense. I can understand that different developers will have their own perspective.
In some cases micro performance factors such as highlighted in this video make a genuine difference to your bottom line or your user's experience.
However, in the vast majority of code being written today it doesn't. This leads to the VS suggestion to use the clearer syntax to be a sensible one. It certainly isn't a "wrong" suggestion as the video intimates.
@@codingbloke You have absolutely no statistical data to the claim that vast majority of code written today are not performance dependent. You are obviously repeating the same rhetoric you have heard over the years.
Meanwhile that spread operator is NOT more readable than traditional ways of doing it.
@@anm3037^rhetoric" more nonsense.
Here is another assertion that will upset you. Most performance sensitive code isn't being written in C#.
Tbh, I kinda disagree with the spread operator syntax being "clearer" in the first place.
If someone who has not kept up with the latest C# language features reads "something.ToArray()", then it is _very_ clear what this piece of code does.
If that same person sees "[.. something]", then they - unless they by chance know that syntax from other languages - will have absolutely no clue what is going on.
One is intuitive, because all it requires you to know is English. The other is yet another piece of "clever" syntax that will make code more concise for specific people in specific situations, but is overall a net minus in code expressiveness when you take the average C# developer into account. Of course if you write code that is only ever read by yourself or better-than-average skilled people then it doesn't matter.
How much does performance matter to you?
Source code available at: github.com/JasperKent/Spread-Benchmark
Remember to subscribe at ua-cam.com/channels/qWQzlUDdllnLmtgfSgYTCA.html
And if you liked the video, click the 👍.
It matters to me very well.
I have a feeling that this is going to get fixed in the next .NET version. Maybe the problem is a bit more complicated than I'm giving it credit for, but I'm pretty sure the solution would involve the compiler checking all the types within spread statement, and if they are all arrays, lowering it to the more optimized version.
I'd have thought so.
They said optimisation and performance for collection expressions are coming in C# 13
you has read all books :/ :/ 🥲
About 60%.