Performance is a feature! - Developer South Coast - part 1
•Descargar como PPTX, PDF•
0 recomendaciones•825 vistas
Starting with the premise that "Performance is a Feature", this session will look at how to measure, what to measure and how get the best performance from your .NET code. We will look at real-world examples from the Roslyn code-base and StackOverflow (the product), including how the .NET Garbage Collector needs to be tamed!
Recomendados
Recomendados
Más contenido relacionado
Similar a Performance is a feature! - Developer South Coast - part 1
Similar a Performance is a feature! - Developer South Coast - part 1 (20)
Más de Matt Warren
Más de Matt Warren (8)
Último
Último (20)
Performance is a feature! - Developer South Coast - part 1
- 1. Performance is a Feature!
- 2. Performance is a Feature! Matt Warren ca.com/apm www.mattwarren.org @matthewwarren
- 4. Why does performance matter? What do we need to measure? How we can fix the issues?
- 5. Why? Save money Save power Bad perf == broken Lost customers Half a second delay caused a 20% drop in traffic (Google) Internal L.O.B apps
- 6. Why? “The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry.” - Henry Peteroski
- 7. Why? Premature optimization is the root of all evil v. Backing yourself into a corner
- 8. “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
- 9. Never give up your performance accidentally Rico Mariani, Performance Architect @ Microsoft
- 12. "most people have more than the average number of legs" - Hans Rosling
- 16. Based on an original idea by Gil Tene from “How NOT to Measure Latency”
- 31. What? Only part of the story
- 32. When? In production You won't see ANY perf issues during unit tests You won't see ALL perf issues in Development
Notas del editor
- Who has: - any perf requirements - perf requirements with numbers! - any perf tests - perf test that are run continuously
- Who has: - any perf requirements - perf requirements with numbers! - any perf tests - perf test that are run continuously
- Save money when running in the cloud (Zeeshan anecdote) - Scale-up rather than just scale-out - Save power on mobile devices (also bad perf more obvious on constrained device) - To users bad performance looks like you're website isn't working! - PerfBytes podcast, "News Of The Damned", a.k.a "which UK ticketing site has crashed this week"! - Bad performance might be losing you customers, before you even got them!! - Even internal L.O.B apps - What could Dave in accounting do with an extra 50 minutes per week (10 min per/day) - Maybe the really slow accounting app is the reason for him quitting and going to work for your main competitor!!
- A.K.A you’ll save a lot of time and effort if you design for performance in the first place. It’s a balance. Sometime perf is forgotten about in the name of YAGNI Sometime maintainable code is written (in the wrong place) in the name of perf!
- To know the critical 3%, we have to measure, Except Donal Knuth, who never write slow code and if he did, he would know which bit was slow!
- Thanks him for making Visual Studio faster He helped fix it after adding WPF made it SLOW!!!!
- Should be roughly 10-15 mins in by now, if not hurry up!!!!
- Normal distribution Things like height, weight, DOESN’T apply to everything!!
- Average is just less than 2, i.e. 1.995 or something like that But > 99% of people in the UK have 2 legs (more than the average)
- This is a histogram, Real-world example Web page response times Why are there 2 groups of histograms bar? - fast = cached data - slow = hitting the database
- Channel out inner Dilbert and educate the Pointy-haired Boss!!
- Ask "Any questions so far?” At this point should be ~20-25 minutes in i.e. just under half-way!!!!!!
- Only the start of the conversation!!! Deliberately didn't cover - Browser page load time v. Server-only time - Peak v. Quiet times - Production and/or Development - How will it be measured? - How will it be enforced?
- Unit tests are meant to be fast, and they only test 1 thing In dev you don’t always have a full set of data You don’t test for long periods of time Smaller setup Michelle Bustamante talk about logging, don’t just need to measure things, Need to log the data AND be able to get at it!!
- Repeat questions back to the audience!!!!!