I was wondering on the breadth of optimization with .NET JIT compiler.
Let's presume I have an assembly of static classes - mostly helper
functions. Some of these functions may be very small (small enough
that the optimizing compiler would inline them).

If I have another assembly that references this helper libary
assembly, could .NET's JIT compiler inline compile the usage of these
small helper functions?

ThomasR <(E-Mail Removed)> wrote:
> I was wondering on the breadth of optimization with .NET JIT compiler.
> Let's presume I have an assembly of static classes - mostly helper
> functions. Some of these functions may be very small (small enough
> that the optimizing compiler would inline them).
>
> If I have another assembly that references this helper libary
> assembly, could .NET's JIT compiler inline compile the usage of these
> small helper functions?

Having done a bit of testing, it doesn't *appear* that it can - at
least not as far as I can see.

I tested this by creating a helper class with two methods, one with
[MethodImplAttribute(MethodImplOptions.NoInlining)] specified. This I
compiled into a library of its own.

I then create a second class which was much the same, but compiled it
along with the benchmarking app. Both methods took roughly the same
length of time for the "out of assembly" version, which was about the
same length of time as the non-inlined "in-assembly" version. The "in-
assembly" method which *was* inlined took significantly less time.

This is slightly worrying, I must admit...

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

> If I have another assembly that references this helper libary
> assembly, could .NET's JIT compiler inline compile the usage of these
> small helper functions?

Although I can't give a definitive answer, I would guess that yes it will
inline across assemblies. I say this as the MSIL is compiled to native
assembly by the JIT so there is really no reason for it not to.

Another reason is patly down to the article:
http://msdn.microsoft.com/library/de...us/dndotnet/ht
ml/highperfmanagedapps.asp which lists some of rules used by the JIT when it
is deciding whether to inline a method or not. Whilst the article explicitly
states that not all rules are presented, I would have thought
'cross-assembly' would be a significant rule (though once again, my
viewpoint may differ from the actual authors .

You're not guaranteed a method is inlined however and the rules may change
in future revisions, so I wouldn't spend whole amounts of time worrying
about whether a method is lined or not until you start running into
performance problems with it

For a more insightful look into the JIT, the
microsoft.public.dotnet.framework.performance newsgroup may get you a more
in-depth and definitive answer.

n!

Jon Skeet [C# MVP] <(E-Mail Removed)> wrote:
> Having done a bit of testing, it doesn't *appear* that it can - at
> least not as far as I can see.
>
> I tested this by creating a helper class with two methods, one with
> [MethodImplAttribute(MethodImplOptions.NoInlining)] specified. This I
> compiled into a library of its own.
>
> I then create a second class which was much the same, but compiled it
> along with the benchmarking app. Both methods took roughly the same
> length of time for the "out of assembly" version, which was about the
> same length of time as the non-inlined "in-assembly" version. The "in-
> assembly" method which *was* inlined took significantly less time.

I've just done a bit of further testing - and it looks like a
*property* call *is* inlined across assemblies. My previous version was
just calling a method which incremented a counter. Adding a property
for that counter and using helper.Count++; came out over twice as fast
as the method call, which suggests it's being inlined.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

> Having done a bit of testing, it doesn't *appear* that it can - at
> least not as far as I can see.
>
> I tested this by creating a helper class with two methods, one with
> [MethodImplAttribute(MethodImplOptions.NoInlining)] specified. This I
> compiled into a library of its own.

Hi Jon,
I've just tried a similar test, after reading your mail. But I seem
to be getting different results (entirely possible its my fault .

I created a class inside an assembly with two public properties ["int
Inlined" and "int NotInlined"] and flagging the 'NotInlined' property as you
describe above.
I then wrote a simple test console application referencing the assembly, and
call the Inlined attribute 9999999 times and output the length of time
taken. And the same again but with the 'NotInlined' attribute. The timed
results were:

'Inline' Property: 10.55441ms
'NotInline' Property: 63.79023ms

The only difference between the properties is the 'NoInlining' attribute is
applied to one and not the other. Of course I may still be wrong, and this
is with the 1.0 framework as we're not allowed .NET2003 at work (I can check
with the 1.1 framework when I get home later). Just thought I'd add to your
post, I can mail my test project to anyone interested (maybe I did something
wrong? .

> This is slightly worrying, I must admit...

I will certainly be worried if the JIT can't inline such calls. :/

n!

> I've just done a bit of further testing - and it looks like a
> *property* call *is* inlined across assemblies. My previous version was
> just calling a method which incremented a counter. Adding a property
> for that counter and using helper.Count++; came out over twice as fast
> as the method call, which suggests it's being inlined.

Ahh, that's where my difference is. Sorry, ignore my other post!

n!

Thanks for your answer (and you to Jon!) and for going to the trouble
to dummy up a test scenario. I've not read up on the compiler
attributes to prevent method inlining. Thanks for the tip.


I do need to worry about this now because performance is very
important to this application. We would change architecture and/or
component structures to accomodate inline compilation for certain
classes.


>
> For a more insightful look into the JIT, the
> microsoft.public.dotnet.framework.performance newsgroup may get you a more
> in-depth and definitive answer.

Yea, I thought so to, but this message sat there all alone for 3 days.
Reposting here gets 2 great replies in hours!

Thanks again guys.


"n!" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> > If I have another assembly that references this helper libary
> > assembly, could .NET's JIT compiler inline compile the usage of these
> > small helper functions?
>
> Although I can't give a definitive answer, I would guess that yes it will
> inline across assemblies. I say this as the MSIL is compiled to native
> assembly by the JIT so there is really no reason for it not to.
>
> Another reason is patly down to the article:
> http://msdn.microsoft.com/library/de...us/dndotnet/ht
> ml/highperfmanagedapps.asp which lists some of rules used by the JIT when it
> is deciding whether to inline a method or not. Whilst the article explicitly
> states that not all rules are presented, I would have thought
> 'cross-assembly' would be a significant rule (though once again, my
> viewpoint may differ from the actual authors .
>
> You're not guaranteed a method is inlined however and the rules may change
> in future revisions, so I wouldn't spend whole amounts of time worrying
> about whether a method is lined or not until you start running into
> performance problems with it
>
> For a more insightful look into the JIT, the
> microsoft.public.dotnet.framework.performance newsgroup may get you a more
> in-depth and definitive answer.
>
> n!