Keeping a handle on your transitions in a mixed assembly

[Bern McCarty]

Our project consists of some mixed .dlls and recently we noticed that it had slowed down. When I
investigated I figured out that some inlineable methods of a native C++ type were compiled into (not
inlined) IL methods. Thus we ended up with the standard two entry points with the native one
thunking over to the managed one for native callers.

The thing is, 99.9% of the call-sites to these inlineable methods on this native type are from
native code. Exactly 1 callsite to just a couple of them are from IL. The actual compiland for
the native type is in fact not even in the affected .dll; rather it is in another .dll that contains
no managed call sites to the methods in question at all. The affected .dll contain modules that
include the header for the native C++ type that contains the inlineable method bodies. I guess when
the compiler decides not to inline a method (for whatever reason) you end up with a copy of the
not-inlined method in each .dll that uses it. Makes sense. That way you don't have to dllexport
your inlineable methods.

I surmise that my problem is caused by the single /clr compiland linked into the affected .dll that
includes the header file for the native type and calls a couple of the inlineable methods. I
imagine that I can eliminate the problem by making sure that in the source for that compiland the
header in question is included as follows:

#pragma unmanaged
#include <MyPerformanceS ensitiveNativeT ype.h>
#pragma managed

But this seems quite fragile. This and other headers for native types are going to be getting
#included in /clr compiled compilands by programmers who are not going to know to carefully take
this measure. I need some way to try to enforce it. Ideally I'd get a build-time error the instant
someone did something that would have my native type's inlineable methods getting compiled into IL.
It's not what I want. I want to penalize the managed callers and make them go to native code - not
penalize native callers and make them go to managed code. After all, these are native types with
99% native callers. I don't see a good way to do it. I wish the compiler would automatically
#define/#undef some macro depending upon whether it was in an #pragma managed or #pragma unmanaged
section. Then I could put something like this at the top of my perf sensitive native C++ headers
that contain inlineable methods:

#if defined (CODEGEN_IS_IL)
#error You should not include this header in a pragma managed section.
#endif

It would be even better if I could push the current state, set the current state to unmanaged, and
then pop the original state at the end of the header file. I'm afraid that withtout something to
help me police this it will be quite difficult to keep undesirable transitions from cropping up over
and over as many different programmers work on the project.

Bern McCarty
Bentley Systems, Inc.

[Gary Chang[MSFT]]

Hi Bern,

I wish the compiler would automatically #define/#undef some macro dependingupon whether it was in an #pragma managed or #pragma unmanaged
section. Then I could put something like this at the top of my perf sensitivenative C++ headers that contain inlineable methods:
...

Do you mean you would like the compiler could automatically define some
macro which depends on whether the code was in an #pragma managed or
#pragma unmanaged section, if so, I suggest can submit a product feedback
at:

http://register.microsoft.com/mswish...=EN-US&gssnb=1
Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default...sdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.