What's your worst performance mistake? Let me know in the comments. Source code available at: github.com/JasperKent/List-Versus-Array Remember to subscribe at th-cam.com/channels/qWQzlUDdllnLmtgfSgYTCA.html And if you liked the video, click the 👍.
Something like a open/closed state of a List would be useful to have the best of both worlds. In open state it would act as a regular List and in closed state would be have a fixed size like an Array. To have .closed() method which would change its internal bool state and free up unassigned memory.
The trade-off at the end of the video can be harmful in terms of GC. If you call this code many times, GC time can be longer than iteration over the list with the double check. Especially if you have a web app scenario, having 100 slightly slower requests can be better than having 99 faster requests and one really slow one (when GC happens), for example, if you have a timeout at the client side.
I got such message when running program. Please, give me a tip what's going on? // Validating benchmarks: Assembly ListVersusArray which defines benchmarks is non-optimized Benchmark was built without enabled (most probably a DEBUG configuration). Please, build it in RELEASE.
The basic principles apply way back to the early days of .NET Framework. The top-level statements in program.cs only work in C# 9 or later. For older versions, just put all that code in Program.Main().
I recommend *against* doing this, but if anyone is curious how you would read array elements without bounds checks, like this: int[] arr = new int[10]; // get reference to element at [0] without bounds checks ref int first = ref MemoryMarshal.GetArrayDataReference(arr); // add 4 elements to the reference, making a new reference that points to element at [4] // then dereference it, now you read the fifth element without bounds checks int fifth = Unsafe.Add(ref first, 4); That being said though, if you write a *for* loop for the array, the bounds checks should be compiled away anyway.
What's your worst performance mistake? Let me know in the comments.
Source code available at: github.com/JasperKent/List-Versus-Array
Remember to subscribe at th-cam.com/channels/qWQzlUDdllnLmtgfSgYTCA.html
And if you liked the video, click the 👍.
Your channel is goldmine! Huge respect
I found your channel recently, but I surprised of quality of your videos. Thx for your tutorials 😊
Thank you for the explanation. Always learn things from you ❤
Another gem.
Your channel it's awsome.
Great job!
In hot paths the difference can be between meeting or not meeting requirements.
Something like a open/closed state of a List would be useful to have the best of both worlds.
In open state it would act as a regular List and in closed state would be have a fixed size like an Array. To have .closed() method which would change its internal bool state and free up unassigned memory.
Yeah, but I think you'd still have to do the copy.
The trade-off at the end of the video can be harmful in terms of GC. If you call this code many times, GC time can be longer than iteration over the list with the double check. Especially if you have a web app scenario, having 100 slightly slower requests can be better than having 99 faster requests and one really slow one (when GC happens), for example, if you have a timeout at the client side.
Absolutely. IN the end, with any performance question, you've got to measure what is actually effective.
Beatiful.
I got such message when running program. Please, give me a tip what's going on?
// Validating benchmarks:
Assembly ListVersusArray which defines benchmarks is non-optimized
Benchmark was built without enabled (most probably a DEBUG configuration). Please, build it in RELEASE.
You can only benchmark a release build. See th-cam.com/video/K2lr3VF0wB8/w-d-xo.html
Much thanks!
arrays vs dicts(hash tables), who wins at performance and speed ?
I'll leave it to you to do the benchmarking, but my bet would be on arrays.
Tell me please Jasper, is this example specific only to VS2022?
The basic principles apply way back to the early days of .NET Framework. The top-level statements in program.cs only work in C# 9 or later. For older versions, just put all that code in Program.Main().
11:11 wow
cool, keep it up ._.
I recommend *against* doing this, but if anyone is curious how you would read array elements without bounds checks, like this:
int[] arr = new int[10];
// get reference to element at [0] without bounds checks
ref int first = ref MemoryMarshal.GetArrayDataReference(arr);
// add 4 elements to the reference, making a new reference that points to element at [4]
// then dereference it, now you read the fifth element without bounds checks
int fifth = Unsafe.Add(ref first, 4);
That being said though, if you write a *for* loop for the array, the bounds checks should be compiled away anyway.
As you say - not recommended.