Successfully reported this slideshow.

Performance is a feature! - Developer South Coast - part 1

0

Share

1 of 33
1 of 33

Performance is a feature! - Developer South Coast - part 1

0

Share

Download to read offline

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!

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!

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Performance is a feature! - Developer South Coast - part 1

  1. 1. Performance is a Feature!
  2. 2. Performance is a Feature! Matt Warren ca.com/apm www.mattwarren.org @matthewwarren
  3. 3. Why does performance matter? What do we need to measure? How we can fix the issues?
  4. 4. 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
  5. 5. 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
  6. 6. Why? Premature optimization is the root of all evil v. Backing yourself into a corner
  7. 7. “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
  8. 8. Never give up your performance accidentally Rico Mariani, Performance Architect @ Microsoft
  9. 9. What? Averages are bad
  10. 10. "most people have more than the average number of legs" - Hans Rosling
  11. 11. Based on an original idea by Gil Tene from “How NOT to Measure Latency”
  12. 12. What? Only part of the story
  13. 13. When? In production You won't see ANY perf issues during unit tests You won't see ALL perf issues in Development
  14. 14. Questions? @matthewwarren www.mattwarren.org

Editor's Notes

  • 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!!!!!
  • ×