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:
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 http://blogs.msdn.com/ricom and thank you for watching.