Summary: Some useful links I've posted in assorted places and other random things I'd like to tell you
SeeAlso: Class Specific Performance Comments
Rico Mariani's Articles and Recommendations
This is a brief summary of articles from my blog plus some other interesting findings that I recommend. I try to update this fairly often. Feel free to add comments as appropriate.
PERFORMANCE SIGNATURES: A QUALITATIVE APPROACH TO DEPENDENCY GUIDANCE
This paper describes Performance Signatures, a simple qualitative approach to helping software developers improve their products’ performance. Performance Signatures allow development tools to give as-you-type prescriptive guidance and facilitate improved analysis and interpretation during traditional profiling sessions. Performance Signatures emphasize ease of adoption and prevention of common and/or large mistakes.
Your project is "In Trouble." The Big Boss has just walked into your office and told you that he needs you to save the day. Again?
Which of the following is more likely the culprit of this crisis that has your boss in a panic... A summary of the survery is posted
here A quick graphical view of how the framework measures up. This is showing off some statistics using my allocation complexity metric.
This problem actually comes up pretty often so I thought I'd write a little article about it, and a couple of approaches to solving it.
Basically any time you take an object "Your Object" whose life you want the GC to manage and then create a reference to it from a long lived object you’ve “anchored” the thing and now it will never go away unless you take special steps to do so. The most common case where this happens is where Your Object registers for events from some global event generator that never goes away. Now Your Object won’t go away and neither will anything that it references.
I had an interesting email conversation here at work recently and as usual I can't share it all but I can share some of it because it's generally applicable and perhaps others could benefit from my response. The particulars are really not important at all in any case, the concept is what counts.
What happened was one of my internal groups did a performance study and asked me for some feedback. Now I think this was actually a great little study but I did have an important criticism. It's something that I've written about before. Here's what I wrote them, almost word for word.
In December 2007, I gave this presentation at the Computer Measurements Group CMG2006 conference(http://www.cmg.org). I had previously alluded to it in this posting and I have been waiting to write about it until after the conference.
So for the benefit of those of you who couldn't be there; here's the slides plus some high level points from the talk. I hope you find it at least somewhat interesting.
It's an interesting analysis of (approximately) the raw cost of throwing an exception. A discussion of how some analyses understates the true costs. I thought it would make a fun exercise to think about the approach taken because it is an interesting topic, and the techniques for thinking about the true cost are generally applicable. A solution is also provided in a
later posting I've actually been meaning to write about real time applications for ages so when I was asked to give a talk at MS Gamefest (http://microsoftgamefest.com) I jumped at the opportunity to give myself a hard reason to do the homework.
I've said this before but I like it so much I thought I'd post it for posterity: "Never use the advice of some loudmouth perf expert like me when you could do a nice solid measurement instead." Maybe I'll get it as a tattoo.
Randall Hyde writes this very interesting article where he expounds on some notions I've often discussed in my talks. I'd definately say that our thoughts are one on the subject.
When you are building some kind of web application. If you are care about customer perceptions of performance -- latency is king. In fact this is pretty much true on the client as well but in server applications, there's just no question. Latency is El Supremo.
Sometimes people ask me what the overhead of array range checking is. A while ago I did a quickish experiment to measure the cost of the bounds checking introduced by the JIT in a typical application. This is just one part of the managed safety net but
A Series on Locking
We have a set of guidelines we publish in the
Performance PAG but there are few examples to support these or elaborate on the seemingly arcane rules. So I thought I'd write some articles to make the concepts a little clearer. These are the results (so far)
*
Locking -- Isolation -- Unit of Work -- Performance *
Locking -- Isolation -- Unit of Work -- Performance -- Solution *
Simplify your locking strategy -- simpler is better *
Putting your synchronization at the correct level *
Putting your synchronization at the correct level -- Solution A big problem we faced in Olympus (Visual C++ 4.0) was that compile times within the IDE were significantly slower than they were if you did the same compile from the command line. It was pretty easy to see that the reason for this was that the IDE was using memory (and doing processing) during the build and so there was less available for the compiler/linker hence a little more swapping and slower builds. My job was to get the IDE's footprint to be as small as possible.
What do you do when faced with a no-kidding-around hard performance situation. Maybe the design was done carefully. Maybe some other smart people have come along and already done all of the obvious tuning steps. So you run the profiler and there are no hot spots. What now?
I sometimes see funny locking patterns because there is a mental assumption that the lock keyword (via Monitor features of the runtime) automatically guards the contents of the locked region. This isn't the case. All that is guaranteed is that only one thread can hold the monitor (i.e. the locked object) at any moment. This doesn't result in resource protection at all unless you, by policy, always take the same lock when accessing the same resource.
While doing performance tests (in 1998) we noticed an interesting phenomenon which motivated us to think about how the Windows NT heap was working for us. What we noticed was that regardless of our web page throughput, page faults per second stayed pretty much constant. In the same way that clock speed is ultimately binding, it seemed that the OS's ability to handle page faults was forever our bottleneck. And so, much of what we did was work to reduce the number of page faults per HTTP request. If faults/sec is constant then its easy to see that your throughput is determined almost completely by the number of page faults per request.
Before I worked on the CLR I spent several years in MSN. One of the big projects I worked on was "Sidewalk" which among other things offered a yellow pages service. A lot of this work was done under IIS with ISAPI extensions and you can imagine the fun involved in writing a lot of native code that needs to deliver great sustained performance. It was very very difficult. In my opinion one of the best features of ASP.NET is that performance doesn't tend to decay over time. I bet a lot this would never have happened if we had been running on say Windows Server 2003 as the system heap is much better but it's still an interesting story.
Perhaps at first blush you might think that it would be easy. After all performance planning, like many other quality aspects, is about creating a better product for your customers in a better way. It’s about having more control, making deliberate choices, and understanding and controlling your risks.
How could anyone in their right mind possibly disagree with value of these things? It should be as easy as selling a no-calorie fat-free dessert that tastes as good as the best ice-cream you’ve ever had. Why isn’t it?
Modern processors and
air jordan 11 are very complicated and sometimes that means that when doing work in one area you actually cause a cost in another area. For instance suppose you have an algorithm that does some computation in a manner that is very unfriendly to the processor's cache but otherwise finishes comparatively quickly; let's suppose it takes 10% of the total time. If you were to eliminate that code you would save not only the 10% time that is spent doing the computation you would also still have good stuff in your cache so the rest of your program would run somewhat faster as well. As a result you could get much more than a 10% cost savings
If it feels like getting good performance out of your application/library/service/whatever is more like "trench warfare" than it is like "shock and awe" then you're probably doing something right.
The trouble with performance work is that the easy work gets all the press. Well, sort of.
If you expend all your performance effort at any one stage in your project’s life then you can expect a disaster. Instead balance the time you have available and invest in performance in appropriate ways throughout the cycle.
When is a Private Byte not a Private Byte? The Private Bytes counter reports the commit charge of the process. That is to say, the amount of space that has been allocated in the swap file to hold the contents of the private memory in the event that it is swapped out. This is not the same as the amount of actual private bytes in memory, or even the peak private bytes in memory. Be careful using this counter as it can be deceiving. Use vadump to get a clearer picture of the true cost in private bytes of memory.
I'm often asked "What's new in Whidbey" and so I thought I'd put together this (very) brief list of some of the more important items that got attention during this product cycle. This is by no means exhaustive but it's a taste of some of the nice improvements you'll see performance-wise.
I think as a performance professional a big part of my job, especially internally, is to remind people of the importance of performance work so that they make their own good choices. It's all part of making success in the performance space something that your team members can achieve. The alternative is to have your performance people running around in other peoples' code bases making changes by fiat (rather than by collaboration) or else having some kind of Performance Czar who makes the big decisions. What might working with the Czar be like? Maybe like this parody of Col. Nathan R. Jessup from 'A Few Good Men.'
""My last entry was some generic advice about how to do a good performance investigation. I thought it would be good to follow up the generic advice with some specific suggestions for things to look at. These are things I look at in step 2 or 3 of the investigation phases described in the last entry.""
""I find that sometimes people have difficultly just getting started when doing a performance analysis – meaning they’re faced with a potentially big problem and don’t know where to begin. This article distills my Modus Operandi into some simple steps to get you started.""
""Sometimes it's difficult to figure out which of your
IDisposable objects is not being disposed properly. This article gives some useful tips on how to track down Disposable object leaks.""
This is basically just advertising the recently published video of the same name in the Designing .NET Class Libaries series
This article discusses 5 main reasons why processor pipelines stall resulting in less than the maximum performance and discusses how managed code helps/hinders these issues.
A short paper written by my colleague
Vance Morrison which I edited for the web. The paper describes code quality issues in managed code and their underlying sources.
This paper deals with the question of when to write your own basic types, like collection classes and what kinds of problems you might encounter if you do.
A simple 7 step process for using SOS to find managed memory leaks. The article includes links to all the necessary tools as well as some other useful background information.
A discussion of cases where calling GC.Collect() is appropriate (and my extension cases where it's not such a good idea).
Pointer to the channel9 video with
JasonZ introducing to some CLR members including me. Some fun advice included.
More useful advice for developers writing managed libraries. This one discusses some issues around the requirements you should put on low level functions in seven basic principles.
My reaction to being quoted by the Java Performance Tuning newsletter. In short, I think they read far too much into my words.
Some considerations for how to plan for better cold startup performance. The overall message is that your time will be dominated by I/O so space issues are king.
Don't get buried in details -- that's the path to premature optimization. But DO plan in an manner that's appropriate for your system. Use performance planning as one of the ways that you control the overall risk of delivering your system.
Here are some comments from a recent discussion on Generics that I thought were generally useful. The comments have been edited so that they fit better with the general format of a Q&A session.
Take the time to understand features well before you use them. Understand the cost of each feature that you intend to use. Don't use features just because it is easy to do so -- do it because a specific problem is solved (well) by the feature.
Getting guidelines for the quality of your service is really about understanding your customers. Use those to decide what to track about your product as you make changes over time.
I renamed my blog after I wrote this because I liked the thought so much. The article is essentially about oop features that are often over used and advises caution while illustrating some costs. This article was/is one of the most popular I've ever written.
People are creating and throwing an exception at the same place, usually when a problem occurred. Does it hurt if someone creates an exception in a static construction, then throw it later? Answers in this article.
I was looking at
Brad’s blog one morning and I was astounded to find that some people had chosen not to use foreach “Because Rico said so” though they probably didn’t use those exact words. I found that very troublesome for several reasons so I thought I’d offer some comments here.
Putting on my "database guy" hat, I was asked to comment on locking techniques for databases and to point out some problems with using transactions as a pessimistic locking technique. Here's what I said...
Is there a way to browse and cleanup allocated resources on request completion for webservice? I have 35% of memory allocations going into strings. The GC now has a mechanism to specify memory pressure, how can we use this to put a ceiling on string allocations? Answers within.
This was my first article on that theme, which was reprised not too long afterwards in a video:
Designing .NET Class Libraries: CLR Performance Tips I wrote a little bit on Disposable objects and their uses in
Chapter 5 of the Performance and Scalability ""PAG"" and it triggered a lively discussion here at MS the other day. Here’s the bit of interesting discussion reduced to ""Q&A"" form.
I think the most important thing to remember about serving data from a database is that, as a practical matter, you can’t realistically serve data that you know to be absolutely current. This is something you should plan for and take advantage of.
""Notes on MethodImplOptions.Synchronized"" original and followup
A reader asked about some clarification on the
“MethodImplOptions.Synchronized” option as described in
Chapter 5 of the Performance and Scalability PAG.
What is the difference between enumerating an array using for versus foreach? What is the recommended practice and why? I did a quick analysis.
I whipped up this guide to help people on internal teams take some of our larger goals and think about them as they apply to their own area. I thought a lot of the advice was generally applicable to managed library authors so I rewrote it for a wider audience and I offer it here with my usual disclaimers. This became the basis for this video
Designing .NET Class Libraries: CLR Performance Tips Many years ago I was invited to give a guest lecture at the University of British Columbia and today I happened to be looking through some material from that time and I was reminded of the talk. My notes are just point form slides and there's supposed to be explaination, examples, exceptions, that go with each point but even without the discussion it's still kind of interesting so here it is for your enjoyment, entertainment, or both.
A brief essay on why space is actually a proxy for speed -- especially when trying to squeeze your application onto a smaller machine. See also
Performance Planning A story about using the statistics of a
Poisson Process to do planning on the number of threads for a system.
I often come across code that has assorted extensibility hooks built right into it. And even nice iron-clad reliability hooks. Indeed Microsoft guidelines suggest these practices and they are surely not evil ones. However, too much of a good thing is not always so good.
I’ve said before that if you make no measurements you’re pretty much doomed to miserable performance. So the only thing worse than no data, is bad data, or badly interpreted data, or both. Details discussed in this article.
Another essay on the problem of
Mid-Life-Crisis and another approach to dealing with it.
We often reach for caches to improve performance. However, it is vitally important to make a deliberate, thoughtful, and justifiable-on-the-numbers choice about policy. It is often the case with framework components that you find yourself too “low” in the architecture stack to understand the usage patterns, or to be experiencing uniform ones. Hence you cannot make excellent choices about caching policy which ultimately dooms your cache to mediocrity. Under those circumstances it's almost always a bad idea to do implicit caching.
A brief discussion of some of the benefits of inlining and the size of function you can be expected to be inlinged with the current Jit compiler.
A few words centered around a key quote: "The obsession with reusable code has produced software that, due to the lack of efficiency, was not even usable, not to mention reusable." This is another ay of warning against oopaholic programming. See the article for additional discussion.
Two Almost Rules describing good practices around throwing exceptions. The central theme is to throw exceptions only for the truly exception cases and provide logic for anything that happen more than say 1/1000th of the time.
I first wrote about this
here, but I've since received several requests for more prescriptive advice on the subject. Again you can never be sure without understanding the exact usage pattern because the results really do vary widely but here's some general guidelines that may be useful.
I wrote this article back in July 2003 and it ended up being the basis of this
videoclrperformance.aspx (scroll to where it says “Thinking about Performance” and choose a speed)
Good locality in your data can make a really big difference to performance (see
Common Sources of Processor Performance Penalties: Five Issues ). How do you get good locality in managed programming? This article discusses some of the issues.
Two very simple almost rules -- the first is Never call GC.Collect() (but see also
When to call GC.Collect) and the second is never have finalizers. Both have their reasons and their exceptions discussed in this article.
An entertaining talk on performance culture, similar to other talks I've given. This article includes the key notes in written form.
When stringbuilders are faster than regular strings it is because of string allocations and copies that didn't have to happen. This article discusses this in some depth, breaking the situation into multiple cases. See also the followup article:
More Stringbuilder advice I saw a posting where someone was considering a great deal of loop unrolling. I can imagine some exotic case where this is a good idea however in general it's more likely to be bad that good. This article discusses the merits of unrolling your loops vs. the space cost and hence speed reduction.
Performance Quizes
*Performance Quiz #12 : Performance Quiz #12 : The Cost of a Good Hash
Problem Hint and
Solution *Performance Quiz #11 : Ten Questions on Value-Based Programming
Problem and
Solution *Performance Quiz #10 : Thread local storage
Problem and
Solution *Performance Quiz #9 :
IList<T> List and array speed
Problem and
Solution (and
Bonus *Performance Quiz #8 The problems with parsing
Problem (a multi part series)
*Performance Quiz #7 Generics Improvements and Costs
Problem and
Solution *Performance Quiz #6 The Chinese/English Dictionary
Problem (a multi part series)
*Performance Quiz #5 The performance cost of the garbage collector
Problem and
Solution *Performance Quiz #4 Of Sets and Sundry
Problem and
Solution *Performance Quiz #3 Rad Parser vs. Classic Parser
Problem and
Solution *Performance Quiz #2 Cost of Computation vs. Storage
Problem and Solution *Performance Quiz #1 Cost of
WriteLine Patterns
Problem and Solution
Other Links
*
Class Specific Performance Comments *
Improving .NET Application Performance and Scalability *
Writing Faster Managed Code -- Know What Things Cost *
Introduction to the CLR Profiler -- Peter Sollich on Video *
Writing high-performance managed applications -- a primer *
Tools that help diagnose managed memory related issues *
Domain Hosting and Domain Neutral Assemblies *
Reflection -- Dodge Common Performance Pitfalls to Craft Speedy Applications *
Memory Analysis from
Tess
Articles related to the Garbage Collector
*
Garbage Collector Basics and Performance Hints *
Using GC Efficiently - Part 1: Fundamentals *
Using GC Efficiently - Part 2: Different GC Flavors *
Using GC Efficiently - Part 3: Pinning and Weak References *
Using GC Efficiently - Part 4: Analyzing your Heap *
GC Performance Counters *
Clearing up some confusion over finalization and other areas in GC
Channel 9: Fishbowl for Facebook
Channel 10: Microsoft Teams Up with Nielsen
TechNet Edge: IT Pro Momentum y Evidencias
