If you missed today’s chat on CLR Performance Tips, you missed a great one!  The transcript should be posted soon.  Top dogs from Microsoft were there: Joe Duffy, Brad Abrams, Krzysztof Cwalina, and 2 of the CLR performance rockstars: Rico and Maoni.

I want to share with you a few of the Q and A’s, of many, that I found interesting and did not know the answers to.  A couple of these were my questions:

Maoni [MS] (Expert): (this was my question)
Q: Are there ways, as coders, to prevent fragmentation, or do we rely completely on the CLR for this? I know pinning objects may cause unavoidable fragmentation, but are there other things that may cause it that we have control over?
A: Yes, take a look the blog entry where I talk about pinning and what good techniques to use if you must pin objects. Another thing you can do is avoiding creating temporary large objects. We recommand using a large object pool where you can recycle the buffers.

Maoni [MS] (Expert): (this was my question)
Q: Does LOH sweep occur everytime a Gen0 sweep occurs?
A: No. It's swept everytime a Gen2 GC occurs

Rico Mariani (Expert):
Q: When refactoring code - are there performance penalties for over-'functionizing' an application?
A: There sure can be. One of the guys that works on profiling tools here says that he sees -- in object oriented languages -- this tendancy to write what he calls "work averse functions." What he means by this is that everything is so factored that there are many many functions each of which does very little and then passes it on to the next function. In straight C programmers don't tend to code that way. The work-averse functions translate directly into much deeper callstacks and much more function call and return overhead. Partly because they're in the worst of all worlds... too big to be inlined yet not big enough to be doing meaty amounts of work. So be careful. Factoring is good but don't go crazy -- you get oophalism that way
A: Yes. Definatelly. Too many short methods that do liitle work called deep on the callstack can significantly affect performance. You should be careful about overfactorizing methods that get called often (in deep callstak loops)

Rico Mariani (Expert):
Q: I suppose the call tree view you are referring to is in CLR Profiler. I've tried to use it on my app but it slows things down so much the app takes hours to startup. Any plans for supporting an "attach" mode for the profiler ?
A: Attach mode is a super popular request but a hard one because we profile by instrumenting the code as it is jitted. However consider this: you can start with profiling disabled, then use the CLR Profiler API to programmatically turn it on just at the perfect spot, and then turn it off again, that limits the log size and reduces the performance hit significantly. Most people with big call trees use CLR Profiler in this way.

Rico Mariani (Expert):
Q: Has there been any work done on reducing the memory footprint of the CLR? I have a rather simple app (1 form, no db access) at it uses over 25mb of ram. Thats pretty high for something so simple.
A: Tons of work was done in this area. Better layout of the image files to reduce working set for instance and of course more sharable pages across multiple running applications. This was a big focus area. Of course you can still burn tons of memory if you allocate like crazy but we've worked hard on reducing the cost associated with the raw code.

Rico Mariani (Expert):
Q: Can you talk about improvements in warm start-up time in 2.0 vs 1.1?
A: We've done tons of work to increase the number of shared pages in our ngen'd images. That was a major focus. That directly translates to improvements in startup time. It's hard to quantify that generally, it will depend on your test case but that was in the cross-hairs of our rifle.

Rico Mariani (Expert):
Q: Why CLR does not inline structs methods calls ?
A: There's no good reason for this... it's high on the list of weaknesses in the JIT. If I had 3 wishes for the JIT team they would be "Better inlining" "Better inlining" and "Better inlining". I believe I've been very clear with them on this point