For the completeinternalasync you are basically making a firstordefault operation with the foreach. A regular old for loop is usually faster than a foreach. Both options are worth testing. You'd likely get a better performance gain by using a concurrent dictionary as a concurrent hashset than the concurrent bag.
ArrayPool. That brings back memories of the embedded software I did 20 years ago. Used a memory pool of fixed size blocks, to prevent using malloc in 99% of the message cases. Always nice to see concepts of decades ago, still show up when needed 😀
Some of the Linq suggestion are already outdated, modern Linq heavily relies on `IIListProvider` (not a typo), that optimizes all 1-to-1 operation over collections. E. g., `myArray.Select(x => x).TryGetNonEnumeratedCount()` will be true because Select is aware that its source is a fixed size collection. This applies to methods like `.ToArray()` or `.ToList()`
It is still relevant actually This is the IL code generated in .NET 6 for the given code in the slide: IL_002a: ldsfld class [System.Runtime]System.Func`2 C/'c'::'9__2_1' IL_002f: dup IL_0030: brtrue.s IL_0049 IL_0032: pop IL_0033: ldsfld class C/'c' C/'c'::'9' IL_0038: ldftn instance bool C/'c'::'b__2_1'(valuetype [System.Runtime]System.Guid) IL_003e: newobj instance void class [System.Runtime]System.Func`2::.ctor(object, native int) IL_0043: dup IL_0044: stsfld class [System.Runtime]System.Func`2 C/'c'::'9__2_1' IL_0049: call bool [System.Linq]System.Linq.Enumerable::Any(class [System.Runtime]System.Collections.Generic.IEnumerable`1, class [System.Runtime]System.Func`2) IL_004e: brfalse.s IL_0060 As you can see at IL_003e it still allocates new func
That's a fair comment. I think I mentioned during the talk that some of the optimizations will no longer be relevant over time because LINQ gets more and more optimized with newer versions of the runtime/bcl. Yet many of the practices are still relevant to think about on the hot path when dealing with collections. Thanks for the feedback!
Super interesting! Knew some, learned some. Something I am missing are comments. Comments that will tell other / future devs why a foreach is used instead of a LINQ, or why the "manual" memory manipulation. Do you include those benchmarks in your code base as a justification / documentation? Or maybe in your unit tests? Because you also want to prevent someone undoing something just because they think the code is too complicated. Also, maybe you could sepak about how do you weight performance vs less-intuitive code? You also mention that you analized the error caees of a method and decised a try was not necessary. Understanding how did you precisely evaluate that can help a lot! Thanks for the talk :)
Thanks for the feedback! I do agree, comments are a necessary and helpful way to indicate to peers or ourselves in the future why a code has been written in a certain way. Another tool I use is to document some additional context in the pull request description and in a design decision record. I would have loved to include even more content (which I have in the repository I linked in the talk, but 60min is the timeslot I had :) ) When it comes to the benchmarks and where to put them, this depends on the performance culture that you have already incorporated. I have a talk upcoming that goes into that ;) Long story short is that I have used multiple approaches with pros and cons. Placing the benchmarks into a dedicated repository, adding them alongside the code into the same repository or just adding it as snippets to the pull requests I have done to third-party repositories. For regression testing, the more important question is probably though the infrastructure you use to get reliable results (hint for example github action runners are not a good runtime environment) and how to make them comparable.
It's great to see that there is at least some return on investment. But I honstly do not understand why someone would work for a big corporation without any financial reward considering that this corporation is turning each and every contribution to Azure into money. I mean its one thing to contribute to common technologies like .NET itself that's freely available. But Azure?
To be fair I contributed to the Azure NET SDK which is freely available according to your definition. But yes eventually you have to pay for the services. For me it was really about doing learning on a real world and big code base to turn my learnings into some impactful that expands my learning.
The existance of systems working on a large scale doesnt imply high performance. If you build an application which can scale horizontally without much issue and isnt limited by shared resources, it doesnt matter if a single server makes 1k RPS or 2k RPS as long as you have the money to pay for the resources.
utilizing this server fully is however rly important. if you process something and after that you transfer the result, you utilize cpu and network or storage bandwith in sequence. if you break it down to use both at the same time you still have the same workload but the user is already getting results while processing. also this broken down task allow for vertical scaling on a finer granularity
@@ndchunter5516 we might be talking about different topics. I was reffering to the claims at the beginning of the video, which said that C# is a high performance language as proven by the fact that there are high workload services running on C# clusters.
“Practical learner” been there many a times; you’re not alone!
Thank you ❤
For the completeinternalasync you are basically making a firstordefault operation with the foreach. A regular old for loop is usually faster than a foreach. Both options are worth testing.
You'd likely get a better performance gain by using a concurrent dictionary as a concurrent hashset than the concurrent bag.
Great presentation, thank you!
Thank you!
ArrayPool. That brings back memories of the embedded software I did 20 years ago. Used a memory pool of fixed size blocks, to prevent using malloc in 99% of the message cases. Always nice to see concepts of decades ago, still show up when needed 😀
Yep 😂 and I have implemented my own pooling mechanisms before on top of dictionaries with locks and later on concurrent dictionaries. Good memories
Awesome presentation. 🙂
Thanks alot!
Thank you for leaving your feedback!
Some of the Linq suggestion are already outdated, modern Linq heavily relies on `IIListProvider` (not a typo), that optimizes all 1-to-1 operation over collections. E. g., `myArray.Select(x => x).TryGetNonEnumeratedCount()` will be true because Select is aware that its source is a fixed size collection. This applies to methods like `.ToArray()` or `.ToList()`
It is still relevant actually
This is the IL code generated in .NET 6 for the given code in the slide:
IL_002a: ldsfld class [System.Runtime]System.Func`2 C/'c'::'9__2_1'
IL_002f: dup
IL_0030: brtrue.s IL_0049
IL_0032: pop
IL_0033: ldsfld class C/'c' C/'c'::'9'
IL_0038: ldftn instance bool C/'c'::'b__2_1'(valuetype [System.Runtime]System.Guid)
IL_003e: newobj instance void class [System.Runtime]System.Func`2::.ctor(object, native int)
IL_0043: dup
IL_0044: stsfld class [System.Runtime]System.Func`2 C/'c'::'9__2_1'
IL_0049: call bool [System.Linq]System.Linq.Enumerable::Any(class [System.Runtime]System.Collections.Generic.IEnumerable`1, class [System.Runtime]System.Func`2)
IL_004e: brfalse.s IL_0060
As you can see at IL_003e it still allocates new func
That's a fair comment. I think I mentioned during the talk that some of the optimizations will no longer be relevant over time because LINQ gets more and more optimized with newer versions of the runtime/bcl. Yet many of the practices are still relevant to think about on the hot path when dealing with collections. Thanks for the feedback!
Great talk. Great presentation.
Thanks for the feedback 🎉
Great presentation.
Thank you for taking the time to make this comment!
I really like how C# evolves into Typescript and TS evolces into C# :D
Haha. You are not wrong 😂
They both are created by the same guy - Anders Hejsberg
Super interesting! Knew some, learned some.
Something I am missing are comments. Comments that will tell other / future devs why a foreach is used instead of a LINQ, or why the "manual" memory manipulation. Do you include those benchmarks in your code base as a justification / documentation? Or maybe in your unit tests? Because you also want to prevent someone undoing something just because they think the code is too complicated.
Also, maybe you could sepak about how do you weight performance vs less-intuitive code?
You also mention that you analized the error caees of a method and decised a try was not necessary. Understanding how did you precisely evaluate that can help a lot!
Thanks for the talk :)
Thanks for the feedback! I do agree, comments are a necessary and helpful way to indicate to peers or ourselves in the future why a code has been written in a certain way. Another tool I use is to document some additional context in the pull request description and in a design decision record. I would have loved to include even more content (which I have in the repository I linked in the talk, but 60min is the timeslot I had :) )
When it comes to the benchmarks and where to put them, this depends on the performance culture that you have already incorporated. I have a talk upcoming that goes into that ;)
Long story short is that I have used multiple approaches with pros and cons. Placing the benchmarks into a dedicated repository, adding them alongside the code into the same repository or just adding it as snippets to the pull requests I have done to third-party repositories. For regression testing, the more important question is probably though the infrastructure you use to get reliable results (hint for example github action runners are not a good runtime environment) and how to make them comparable.
why this is a video? 😍😍😍😍😍😍
It's great to see that there is at least some return on investment. But I honstly do not understand why someone would work for a big corporation without any financial reward considering that this corporation is turning each and every contribution to Azure into money. I mean its one thing to contribute to common technologies like .NET itself that's freely available. But Azure?
To be fair I contributed to the Azure NET SDK which is freely available according to your definition. But yes eventually you have to pay for the services. For me it was really about doing learning on a real world and big code base to turn my learnings into some impactful that expands my learning.
The existance of systems working on a large scale doesnt imply high performance.
If you build an application which can scale horizontally without much issue and isnt limited by shared resources, it doesnt matter if a single server makes 1k RPS or 2k RPS as long as you have the money to pay for the resources.
However high performance still is very important, as less servers can make a significant impact on the environmental impact of your application.
Using less resources can also be economically sensible, especially when your hardware is fairly expensive, like GPUs.
utilizing this server fully is however rly important. if you process something and after that you transfer the result, you utilize cpu and network or storage bandwith in sequence. if you break it down to use both at the same time you still have the same workload but the user is already getting results while processing. also this broken down task allow for vertical scaling on a finer granularity
@@ndchunter5516 we might be talking about different topics. I was reffering to the claims at the beginning of the video, which said that C# is a high performance language as proven by the fact that there are high workload services running on C# clusters.
This is the very bad philosophy. All resources are scarce. Please write efficient code always!