Designing .NET Class Libraries: CLR Performance Tips

Last year I was one of the speakers at some internal training on how to build good libraries.  We liked the series enough that we decided to tidy it up and offer it all as advice to the world.  The talks have been coming out one a week for several weeks now and today mine comes out.  I invite you to check out Designing .NET Class Libraries: CLR Performance Tips as well as the others.  I'm also in the audience Q&A session which will be released in a few weeks.

I invite you to offer any feedback or comments you might have on the talk here.

Links for the full series can be found at:  Designing .NET Class Libraries

By way of a teaser, here are my program notes for this particular video:

Designing great frameworks training: Performance

Helping people to get great performance out of managed code is often as much about helping them have good “performance culture” in their groups as it is about what code you write. In this talk I stress the benefits of good process with simple rules like “Measure” and “Do Your Homework” and processes for getting your requirements from customers – and meeting them – like “Budget, Plan, and Verify.”

It’s my hope that these kinds of thoughts lead you away from thinking about good performance as either a set of traps you should avoid or some silver bullets you should use but rather as something that you must engineer into your design at every step by making decisions on a quantitative basis – understanding the ramifications of your choices in terms of metrics that matter to your customers.

If you’re not measuring you’re not engineering.

After the cultural aspects I discuss some good general guidelines for data structures emphasizing simplicity (avoiding “oopaholic” design) and good locality as well as making sure that each feature we add is “a good deal” for our customer. The general theme is that using the simplest method that meets your needs rather than more general programming construct often leads to the best designs. In many important cases (hashing functions, comparison functions) the simple choice is the only reasonable one. Included are a few cautionary tales about cases where we ran into problems because we didn’t follow these rules.

Lastly I discuss some typical performance planning goals. Things like managing your working set, or budgeting your startup time. Fairly simple approaches for modeling these can help you to get a handle on where your greatest challenges will lie – and hence where you should be putting the bulk of your effort.

Like the others, this talk was intended for an internal audience and so I’m sure there are bits where my advice is less applicable to your own organization but I hope at least some of it is helpful. Many of the topics have been discussed on my blog in greater detail, please visit and thank you for watching.

Comments (11)

  1. James Curran says:

    Click this link:

    Gets me this error:


    String was not recognized as a valid DateTime.

  2. BillT says:

    Mmmmmm-mmmmm, Rico, this is all great stuff! I’m so glad you prepped this for public release.

  3. Raj says:


    Just went through your presentation – I think this is something that every computer science student should see. Thanks for sharing this. I particularly liked your section on "Working Set" and also the notion of "If you are not measuring you are not engineering". Very informative indeed.



  4. Ollie says:

    Finally put a face to the name….

  5. theCoach says:

    oopaholic is a great term. Do you think it is possible for developers using Java to become Oopaholics?

  6. Rico Mariani says:

    I first heard the phrase applied to C++ developers… I don’t think it’s language specific. Oophalic design is very common.

  7. Barry Kelly says:

    I’m looking forward to watching the video when it becomes available to download.

    It is, right?

    I do hope so, I’ve watched all the others that are downloadable in the series, excellent food for thought so far, especially the one by Steve on API usability.

  8. Having spent 3 weeks on the road talking to different customers about software development and coming…

Skip to main content