I've been working on an idea here in my "spare" time for quite some time now -- basically in response to the fact that there is so much .NET Framework to cover and so little in the way of pervasive performance information about it.  Time and again I'm approached by people who would like there to be some set of rules they could follow for usage -- which APIs are good to use in which contexts.  And maybe some way of getting warnings and advice at design time and when troubleshooting.

I came up with the idea of using "Performance Signatures" to describe, very roughly, the performance characteristics of any given API.  I submitted the idea plus some very preliminary results to The Computer Measurement Group -- CMG -- I didn't say anything about it here because the refereeing process was to be blind on both ends.

ABSTRACT: This paper describes a simple qualitative approach, through approximate Performance Signatures, that allows prescriptive dependency guidance to be given in real time and facilitates improved analysis of measured results. Emphasis is placed on ease of adoption and preventing common/large mistakes
 

On Monday I heard back from CMG with these details: 

Dear Rico:

Congratulations! It is my pleasure to notify you that your paper “Performance Signatures:  A Qualitative Approach to Dependency Guidance” has been accepted for the CMG2006 conference to be held December 3 - 8, 2006, in Reno, Nevada. The Program Committee has scheduled your paper for the following session... 

Author/Firm:        Rico Mariani / Microsoft Corporation
Session Number:     626
Subject Area:       Fundamentals/Core Competency            
Day, Time:          Friday  [Dec 8] 10:30 AM - 12:00 PM
Session Length:     60 minutes

Which means I'm heading down there to give a talk on the subject and hopefully meet some interesting people that are also in the performance business.

If you're interested, see http://www.cmg.org/ for more details.  Maybe I'll see you there!

In the interest of not massively pre-releasing the contents of the paper I'll shush about it until after the conference.