Share via

Pithy Perf Patterns

Maoni Stephens, Perf PM on the CLR team sent me some key “patterns”... You will see I have not expanded on any of them, I am sure we can talk Rico into blogging on any of these at length if we ask nicely....

  1. avoid finalizers; use the Dispose pattern.
  2. avoid the urge of writing your own memory allocator (which is a common thing to do in native world)
  3. avoid having the object pattern of lots of midlife-ed objects
  4. use chunky instead of chatty interfaces in interop, and avoid marshaling complex types if you can
  5. use the ThreadPool instead of managing your own threads
  6. use caches to avoid doing the same things again and again (of course this applies to native world as well but we've seen so many cases where people do this - like fusion parsing the same manifest again and again and etc)
  7. don't throw exceptions when you don't have to - throwing exceptions is expensive in managed world
  8. know the hidden cost (examples include using foreach; when boxing happens; when reflection is involved)
  9. don't use XML without thinking! (again, also applies to native - DOM is slow too but I guess the managed xml classes are so easy to use and we've seen so many cases where people abuse using xml).
  10. And this important thing applies to all: "pay for play" - only do things when you need to.

UPDATE: Maoni pointed out to me that I left off her most important rule... "With perf there are rarely absolutely rules so we need to tell people why they want (or not want) to do these so they can decide for themselves " It is a good rule indeed.

Also, notice you can always find good perf info on Rico's blog.

Comments

  • Anonymous
    January 09, 2004
    The comment has been removed

  • Anonymous
    January 09, 2004
    It's funny how things work out. I suspect the email that Maoni sent Brad was distilled from the slides she and I made for a talk we gave together a few weeks ago which was in turn distilled from recent entries on my blog so I've already actually commented on most of those.

    See http://weblogs.asp.net/ricom/

    Now the particulars of XML and the XML DOM is that I often find folks picking up the (sledgehammer of an) XML parser to parse, at great expense, a comparatively small amount of data. Often precisely because it is so easy to do just that.

    This isn't always the wrong thing to do of course; We each have to make choices as to where to invest our time, both processing time and development time. But, and this is especially true for simple configuration data, there are comparatively few benefits to using XML and the cost could be higher than you want to bear. So that advice makes our greatest hits list because it's a common pitfall. And not The Pit of Success.

    So #9 simply boils down to make an informed decision. Doing anything by reflex is a recipe for Big Trubble.

  • Anonymous
    January 09, 2004
    Check out "Improving .net Application Performance and Scalability"

    http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=540f8bd7-be95-45f7-a477-919d23294553

  • Anonymous
    January 09, 2004
    >1. avoid finalizers; use the Dispose pattern

    I'd expand this a bit. If an object implements the Dispose interface then it should also implement a Finalizer as a backstop, and then I would treat it as at least a warning (log it), and possibly an error (throw exception), if the finalizer ever ran. The idea is that the Dispose is a contract that the object requires the client to honor.
    The goal is to catch violations during the debug phase before it ever ships to customers.

  • Anonymous
    January 09, 2004
    Thanks David -- I generally agree with your post, but I might not go as far as you suggest. The Dispose pattern is mostly a perf optimization... That is for correctness the finalizer running is not a bad thing so I would not throw and exception from the finalizer. The Finalizer is a great backup plan.
    We know from experince with COM that developers have trouble explicily freeing instances, I don't want to go back to that world.. We should continue to take advantage of the GC here.

  • Anonymous
    January 10, 2004
    The comment has been removed

  • Anonymous
    January 10, 2004
    but isn't the performance optimization of the suggested use of the dispose pattern over the use of finalizers that your objects don't have to be promoted in the GC so that at some time in the future the finalizer thread can come around and finalize them?

    by putting in a "backup" finalizer it seems that you completly negate that optimization...

  • Anonymous
    January 10, 2004
    The Dispose method calls GC.SuppressFinalize(this) so that the finalizer only gets called if the Dispose method is never invoked, so we still get our perf improvement if the object is used correctly.

  • Anonymous
    January 11, 2004
    I would have before a recent project completely agreed with you on ThreadPools instead of managing your own threads. In the Framework 1.0.3705 ( I have not tried the same with 1.1 or higher ) some interesting things happened inside of a Windows Service I had written.

    The threads were in a thread pool using the Threading timer. The first thing I noticed was my first thread created was always favored. The other threads did receive clock cycles, but not as consistently as the first thread did.

    The other thing that happened to me was a mis behaving DataProvider written by a non-Microsoft vendor who shall remain nameless :-) threw an unknown exception. This in itself was not a problem, but my next call into that provider went to never, never land. Again no problem except that at that point all my other threads stopped receiving clock cycles, no ticks ever fired again on any of the threads, but my primary thread and the service were still live.

    I had much code devoted to handling awry thread, but that code never got hit because my app was unaware of the issue.

    Now I have my own threads, spawned by me and a health thread to make sure all my threads are behaving and communicating in a timely matter and no more issues. I still believe in threadpools and I will probably try again in 1.1 to see if the same behavior is exhibited, but for my production code, I'll keep my approach until threadpools win me back.


  • Anonymous
    January 19, 2004
    I would like to see some more information on the threadpool requirement. Is the performance recomendation only because the threads are 'pooled', or is this a case like memory management where rolling your own tends to make things up? I have heard allot of talk refering to the threadpool as having performance limitations, and have seen developers in the field rolling their own threadpools. I think a more thorough treatment of this topic would enlighten many people.

  • Anonymous
    January 23, 2004
    I must say it's a bit odd to hear someone suggest that using XML for a relatively small amount of data is not recommended. Visual Studio defaults all app config files to an XML format, all web app config files to an XML format, the VS project files to an XML format, etc. Often, these XML files hold very little data. Perhaps someone can clarify this for me?

  • Anonymous
    March 02, 2004
    The comment has been removed

  • Anonymous
    January 03, 2008
    Casting in C#

  • Anonymous
    January 03, 2008
    PingBack from http://www.developernotes.com/post/Casting-in-C.aspx

  • Anonymous
    June 09, 2009
    PingBack from http://weakbladder.info/story.php?id=6859

  • Anonymous
    June 17, 2009
    PingBack from http://pooltoysite.info/story.php?id=6918