B
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 <MyPerformanceSensitiveNativeType.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.
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 <MyPerformanceSensitiveNativeType.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.