Inlining Question/Discussion

boo posted on Friday, October 26, 2007

I won't pretend to know much about inling.  Rocky says to put it on the property attributes, so I blindly do it without question.

So tonight I went to find out exactly what 'inlining' is (something I've been meaning to do for a few years now); appears to be JIT optimizations.  But while reading the below blog where I got this information from I found that it appears JIT won't inline method targets that are MarshalByRef...so do we really need to have that attribute on our properties?

http://blogs.msdn.com/davidnotario/archive/2004/11/01/250398.aspx

Again, I don't really understand inlining, but I'm interested in understanding it a bit better, the reason Rocky uses it on properties (and not static methods or instance methods - or maybe he is and I should be to) and how this differs from what the person is saying in the above post.  I know Rocky's a smart guy (and the contribs), so there's a piece of the puzzle I'm missing.

RockfordLhotka replied on Sunday, October 28, 2007

You only need that attribute around methods that call CanReadProperty(), CanWriteProperty() or PropertyHasChanged(), where you use the overload that does not require the property name. If you look at the code behind that overload you'll see that it uses System.Diagnostics to get the stack trace and thus the property name.

If the inlining optimization is applied by the JITter then that technique would fail, and your code wouldn't work correctly.

Since CSLA business objects do not inherit from MarshalByRefObject, that exemption has no meaning here.

As someone recently pointed out in another thread though, apparently there are other optimizations that can make the stack trace scheme fail - specifically in the 64 bit space. So ultimately this technique may be a bust, so in the long run it is probably better to switch to the string literal property name overloads and stop using the inlining attribute.

boo replied on Sunday, October 28, 2007

That's right; it's by value.  It's good to know about this stack trace issue though; I'll send a memo out so that are group starts moving items away from the parameterless calls of the above mentioned methods.  Have these overloads been deprecate in 3.0 CSLA?, in otherwords:

[Obsolete("May cause problems in 64 bit environments", false)]
public void PropertyHasChanged() {...}

RockfordLhotka replied on Sunday, October 28, 2007