PPTX, PDF368 views

Pragmatic Performance from NDC Oslo 2019

This document contains the transcript from a presentation by David Wengier from Microsoft on optimization and performance. It discusses premature optimization, profiling code to measure performance, and that best practices often depend on the specific situation rather than always applying general rules. Key quotes are attributed to Donald Knuth regarding optimizing and a message that recommendations should not be followed blindly without considering the context.

Software◦

NDC { Oslo }
2019
David Wengier
Microsoft
@davidwengier

We should forget about small efficiencies, say about
97% of the time: premature optimization is the root
of all evil. Yet we should not pass up our opportunities
in that critical 3%”
- Donald Knuth
@davidwengier

“Don’t do that, that’s slow, and uses too much memory!”
@davidwengier

https://benchmarkdotnet.org/
https://github.com/dotnet/BenchmarkDotNet
•
•
•
•
@davidwengier

public class HybridDictionary: IDictionary {
// These numbers have been carefully tested to be optimal.
// Please don't change them without doing thorough performance
// testing.
private const int CutoverPoint = 9;

• Should you always use Dictionary<K,V> instead of IDictionary<K,V>?
• Should you always use structs instead of classes?
• Should you always use for instead of foreach?
• Should you always use StringBuilder instead of concatenation?
• Should you always use traditional loops instead of Linq?
• Should you always avoid throwing exceptions?

• Should you always use Dictionary<K,V> instead of IDictionary<K,V>? No, it depends.
• Should you always use structs instead of classes? No, it depends.
• Should you always use for instead of foreach? No, it depends.
• Should you always use StringBuilder instead of concatenation? No, it depends.
• Should you always use traditional loops instead of Linq? No, it depends.
• Should you always avoid throwing exceptions? No, it depends.
• Should you always … anything? No, it probably depends.

Pragmatic Performance from NDC Oslo 2019

1.
NDC { Oslo} 2019 David Wengier Microsoft @davidwengier
2.
@davidwengier
3.
- Donald Knuth @davidwengier
4.
- Donald Knuth @davidwengier
5.
We should forgetabout small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%” - Donald Knuth @davidwengier
6.
We should forgetabout small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%” - Donald Knuth “Structured Programming with Go To Statements”, 1974@davidwengier
7.
@davidwengier
8.
@davidwengier
9.
@davidwengier
10.
“Don’t do that,that’s slow, and uses too much memory!” @davidwengier
11.
public static voidProfile(Action func) { DateTime start = DateTime.Now; for (int i = 0; i < 100; i++) { func(); } Console.WriteLine(“Avg Time Elapsed {0} ms", (DateTime.Now - start).TotalMilliseconds / 100); }
12.
public static voidProfile(Action func) { Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.High; Thread.CurrentThread.Priority = ThreadPriority.Highest; func(); Stopwatch watch = new Stopwatch(); GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(); watch.Start(); for (int i = 0; i < 100; i++) { func(); } watch.Stop(); Console.WriteLine(“Avg Time Elapsed {0} ms", watch.Elapsed.TotalMilliseconds / 100); }
13.
https://benchmarkdotnet.org/ https://github.com/dotnet/BenchmarkDotNet • • • • @davidwengier
14.
• • • • • • @davidwengier
15.
• • @davidwengier
19.
• • • • • • • • •
21.
0 bytes allocated32 bytes allocated
22.
• •
24.
0 bytes 20bytes 32 bytes
25.
• •
28.
• •
29.
public class HybridDictionary:IDictionary { // These numbers have been carefully tested to be optimal. // Please don't change them without doing thorough performance // testing. private const int CutoverPoint = 9;
30.
• Should youalways use Dictionary<K,V> instead of IDictionary<K,V>? • Should you always use structs instead of classes? • Should you always use for instead of foreach? • Should you always use StringBuilder instead of concatenation? • Should you always use traditional loops instead of Linq? • Should you always avoid throwing exceptions?
31.
• Should youalways use Dictionary<K,V> instead of IDictionary<K,V>? No, it depends. • Should you always use structs instead of classes? No, it depends. • Should you always use for instead of foreach? No, it depends. • Should you always use StringBuilder instead of concatenation? No, it depends. • Should you always use traditional loops instead of Linq? No, it depends. • Should you always avoid throwing exceptions? No, it depends. • Should you always … anything? No, it probably depends.
32.
@davidwengier

Editor's Notes

#3 Whos heard this? This gets carted out on PRs, and usually as a negative. Either someone changes a linq statement to foreach statement, and someone else says “don’t bother, premature opt…”. Or someone writes a linq statement, someone comments saying it should be a foreach statement, and then in order to be lazy, “premature opt..” But first, Who said it?
#4 Donald Knuth. K-nooth. You may notice the formatting is odd.. Well, that’s because its part of a bigger quote
#5 Most people don’t know this. 97% of the time its evil, the rest its not. But why? Notice the quotes.
#6 Consider maintenance and debugging. Readability. Etc. Bonus points, what paper was it from?
#7 Ironically, a quote that lots of developers spout as being gospel comes from a paper arguing that programming with go to statements is perfectly fine. A debate for another time.
#8 How much? How often?
#9 Questions assumptions: “the compiler will fix this”. Will it? Release builds only!
#10 Measure. Before and After.
#12 DateTime is as precise as stopwatch, but not as granular Doesn’t account for JITing
#13 High affinity, so nothing else on the machine matters (hopefully) JIT first Get GC out of the way, because GC pauses are bad for benchmarking Then go
#14 Or use BenchmarkDotNet
#15 So I’ve told you how to benchmark, and that you should basically never do it, so lets do it.
#16 Except its too slow. Its _thorough_ BenchmarkDotNet is too awesome for live demos. I have some canned ones.
#19 Concat wins Then stringbuilder StringBuilder again Now StringBuilder with capacity, and that trend continues forever If we add more, we can see stringbuilder and string join are both a lot fast As we keep going, the difference gets bigger Looks like a slam dunk right? Always use a string builder with capacity? BUT- don’t forget context!!! Look what happens as the strings get longer. Now it doesn’t matter so much, as long as you don’t concatenate
#20 Back to context, again production code.. For 3 small strings, concatenation is slower, but not measurably so. But it uses less memory. The overhead of StringBuilder might make it a winner. For large strings, not so. Stopwatch granularity is around 300ns, so the difference in the first one is effectively unmeasurable in production .NET code. For large strings SB still uses heaps of memory. Are strings the best thing to use at all? Step back
#22 The overhead of a class vs struct, virtual calls, etc. makes the difference. So if you use Idictionary as your parameters are you’re supposed to do, on a hot path that might be a negative. Question assumptions.. How many of you think “coding to interfaces” is _always_ better?
#24 I’m an old man so I like loops, but Linq has an overhead.
#25 Overhead in method invocations and allocations. Even the Where vs FirstOrDefault examples, because there are more iterators being allocated. Where uses an iterator, FirstOrDefault uses a foreach loop
#27 50% chance of having an invalid number. The important thing is that both benchmarks will use exactly the same input.
#29 Question assumptions!
#30 Culture of performance means measure, not necessarily write complicated code
#32 Pragmatic. Every decision is unique. Don’t write off performance, but don’t write off anything.

Pragmatic Performance from NDC Oslo 2019

1.
NDC { Oslo} 2019 David Wengier Microsoft @davidwengier
2.
@davidwengier
3.
- Donald Knuth @davidwengier
4.
- Donald Knuth @davidwengier
5.
We should forgetabout small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%” - Donald Knuth @davidwengier
6.
We should forgetabout small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%” - Donald Knuth “Structured Programming with Go To Statements”, 1974@davidwengier
7.
@davidwengier
8.
@davidwengier
9.
@davidwengier
10.
“Don’t do that,that’s slow, and uses too much memory!” @davidwengier
11.
public static voidProfile(Action func) { DateTime start = DateTime.Now; for (int i = 0; i < 100; i++) { func(); } Console.WriteLine(“Avg Time Elapsed {0} ms", (DateTime.Now - start).TotalMilliseconds / 100); }
12.
public static voidProfile(Action func) { Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.High; Thread.CurrentThread.Priority = ThreadPriority.Highest; func(); Stopwatch watch = new Stopwatch(); GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(); watch.Start(); for (int i = 0; i < 100; i++) { func(); } watch.Stop(); Console.WriteLine(“Avg Time Elapsed {0} ms", watch.Elapsed.TotalMilliseconds / 100); }
13.
https://benchmarkdotnet.org/ https://github.com/dotnet/BenchmarkDotNet • • • • @davidwengier
14.
• • • • • • @davidwengier
15.
• • @davidwengier
19.
• • • • • • • • •
21.
0 bytes allocated32 bytes allocated
22.
• •
24.
0 bytes 20bytes 32 bytes
25.
• •
28.
• •
29.
public class HybridDictionary:IDictionary { // These numbers have been carefully tested to be optimal. // Please don't change them without doing thorough performance // testing. private const int CutoverPoint = 9;
30.
• Should youalways use Dictionary<K,V> instead of IDictionary<K,V>? • Should you always use structs instead of classes? • Should you always use for instead of foreach? • Should you always use StringBuilder instead of concatenation? • Should you always use traditional loops instead of Linq? • Should you always avoid throwing exceptions?
31.
• Should youalways use Dictionary<K,V> instead of IDictionary<K,V>? No, it depends. • Should you always use structs instead of classes? No, it depends. • Should you always use for instead of foreach? No, it depends. • Should you always use StringBuilder instead of concatenation? No, it depends. • Should you always use traditional loops instead of Linq? No, it depends. • Should you always avoid throwing exceptions? No, it depends. • Should you always … anything? No, it probably depends.
32.
@davidwengier

Editor's Notes

#3 Whos heard this? This gets carted out on PRs, and usually as a negative. Either someone changes a linq statement to foreach statement, and someone else says “don’t bother, premature opt…”. Or someone writes a linq statement, someone comments saying it should be a foreach statement, and then in order to be lazy, “premature opt..” But first, Who said it?
#4 Donald Knuth. K-nooth. You may notice the formatting is odd.. Well, that’s because its part of a bigger quote
#5 Most people don’t know this. 97% of the time its evil, the rest its not. But why? Notice the quotes.
#6 Consider maintenance and debugging. Readability. Etc. Bonus points, what paper was it from?
#7 Ironically, a quote that lots of developers spout as being gospel comes from a paper arguing that programming with go to statements is perfectly fine. A debate for another time.
#8 How much? How often?
#9 Questions assumptions: “the compiler will fix this”. Will it? Release builds only!
#10 Measure. Before and After.
#12 DateTime is as precise as stopwatch, but not as granular Doesn’t account for JITing
#13 High affinity, so nothing else on the machine matters (hopefully) JIT first Get GC out of the way, because GC pauses are bad for benchmarking Then go
#14 Or use BenchmarkDotNet
#15 So I’ve told you how to benchmark, and that you should basically never do it, so lets do it.
#16 Except its too slow. Its _thorough_ BenchmarkDotNet is too awesome for live demos. I have some canned ones.
#19 Concat wins Then stringbuilder StringBuilder again Now StringBuilder with capacity, and that trend continues forever If we add more, we can see stringbuilder and string join are both a lot fast As we keep going, the difference gets bigger Looks like a slam dunk right? Always use a string builder with capacity? BUT- don’t forget context!!! Look what happens as the strings get longer. Now it doesn’t matter so much, as long as you don’t concatenate
#20 Back to context, again production code.. For 3 small strings, concatenation is slower, but not measurably so. But it uses less memory. The overhead of StringBuilder might make it a winner. For large strings, not so. Stopwatch granularity is around 300ns, so the difference in the first one is effectively unmeasurable in production .NET code. For large strings SB still uses heaps of memory. Are strings the best thing to use at all? Step back
#22 The overhead of a class vs struct, virtual calls, etc. makes the difference. So if you use Idictionary as your parameters are you’re supposed to do, on a hot path that might be a negative. Question assumptions.. How many of you think “coding to interfaces” is _always_ better?
#24 I’m an old man so I like loops, but Linq has an overhead.
#25 Overhead in method invocations and allocations. Even the Where vs FirstOrDefault examples, because there are more iterators being allocated. Where uses an iterator, FirstOrDefault uses a foreach loop
#27 50% chance of having an invalid number. The important thing is that both benchmarks will use exactly the same input.
#29 Question assumptions!
#30 Culture of performance means measure, not necessarily write complicated code
#32 Pragmatic. Every decision is unique. Don’t write off performance, but don’t write off anything.

Pragmatic Performance from NDC Oslo 2019

More Related Content

Similar to Pragmatic Performance from NDC Oslo 2019

Recently uploaded

Pragmatic Performance from NDC Oslo 2019

Editor's Notes

More Related Content

Similar to Pragmatic Performance from NDC Oslo 2019

Recently uploaded

Pragmatic Performance from NDC Oslo 2019

Editor's Notes