Avoiding Coding Pitfalls with Performance Signatures

re: Avoiding Coding Pitfalls with Performance Signatures

Pop Catalin Sever — Tue, 12 Dec 2006 01:10:42 GMT

Although "Hi", "Medium" and "Low" isn't that bad for starters I always felled that MSDN should have had a small frame (collapsible, and hidden by default) where cost info should be displayed.

I think some sort of info for CPU cost, memory allocations, "garbage generation", security checks/demands, tread locking, transition to kernel mode, and alike should be available.

Up to now I 'reflectored' my way trough the framework to find the details of implementation and was surprised many times to find security demands or tread locking in places I didn't expect and assumed the former code to be very fast even candidate for inlining.

I'm a very young software and .net developer but almost anything I had to learn about performance was the hard way. Hardly any books or articles touch this subject at a low level and in detail. For this and for learning purposes I had to dissect the framework and/or rotor and spent countless hours examining, watching, taking notes, experimenting, etc.

Also the Intelisense/FXCop immediate feedback idea is great. I would also like some sort of method performance test bench to test my methods (algorithms?) on the fly so I can experiment with different implementations, without doing a custom or full application benchmark.

I definitely thing adding performance guidelines in general, even using a rough scale should help, allot.

Thanks for the great article...as always :)

Rico talks about adding performance data to method signatures

Jeff Abraham's WebLog — Tue, 12 Dec 2006 01:54:24 GMT

http://blogs.msdn.com/ricom/archive/2006/12/11/avoiding-coding-pitfalls-with-performance-signatures.aspx

re: Avoiding Coding Pitfalls with Performance Signatures

Alois Kraus — Tue, 12 Dec 2006 02:27:05 GMT

Very good idea. As code analysis tool this makes perfect sense. But I doubt that during typing my context is always clear and you can give exact guidance there. Since there will be no exact mesurable definition when a function is high, medium or low I guess we would have to stick to an even simpler approach: Costly, vs Cheap where you should be able to define a crystal clear definition what is costly and what not. When you seek the missing factor 20 of performance this clear distinction should do already the job.

Yours,

Alois Kraus

re: Avoiding Coding Pitfalls with Performance Signatures

David Levine — Tue, 12 Dec 2006 20:46:26 GMT

Excellent idea, I like where you are going with this.

Instead of categories like "low, medium, whatever" what do you think about some way of assigning a numeric ranking based estimated performance? I know that sounds like quantitative analysis but I'm thinking more along the lines of orders of magnitude, not absolute numbers. For example, use values of 1 (fast), 10, 100, 1000 (very slow).

Regardless, this might give us an easy way to perform back-of-the-napkin performance estimate using different approaches to solving a problem. It might also make the code more toolable for perf/analysis tools. Perhaps the compiler could analyze the code, generate a perf number, and add it into the metadata with a custom attribute.

re: Avoiding Coding Pitfalls with Performance Signatures

ricom — Wed, 13 Dec 2006 12:30:37 GMT

Log base 10 costs is really where I'm going with this. But it's interesting just how far you can get far with only 3 categories.

It's important to remember that anything like this is only an approximate cost and only usually in one dimension. More costs, more dimensions, etc. are better for performance types (like maybe most of my readers?) but for the everyman keeping this simple and avoiding big mistakes is really a good thing.

Do Performance Analysis in Context

Rico Mariani's Performance Tidbits — Thu, 21 Dec 2006 23:04:33 GMT

I had an interesting email conversation here at work recently and as usual I can't share it all but I

Performance Quiz #12 -- The Cost of a Good Hash -- Some Help

Rico Mariani's Performance Tidbits — Wed, 24 Jan 2007 22:31:16 GMT

I continue to be astounded by what my readers can come up with. As usual I had a purpose for posing my

.NET Framework Allocation Complexity Graph

Rico Mariani's Performance Tidbits — Fri, 26 Jan 2007 21:16:29 GMT

A quick graphical view of how the framework measures up. This graph shows the number of methods of any

.NET Framework 2.0 Allocation Complexity Graph

Rico Mariani's Gallery — Sat, 27 Jan 2007 02:17:31 GMT

This graph shows the number of methods of any given allocation complexity on a logarithmic scale. ...

.NET Framework Cost Metrics

Impersonation Failure — Sat, 27 Jan 2007 17:37:24 GMT

Rico Mariani included a very interesting file in his latest performance quiz post which shows all the

Performance Signatures CMG 2006 Paper

Rico Mariani's Performance Tidbits — Wed, 07 Feb 2007 22:18:33 GMT

I presented this paper at the CMG 2006 conference. I've previously posted the content of my slides and