Hi Juan,

Thanks for Marcus's input and I agree with Juan's suggestion.
The VC and CLR teams have done lots of performance analysis. But there isn¡
¯t a simple answer to this question. Let me say some basic things
/clr:safe code will generally perform as well or often better than the
equivalent C# code, because the C++ optimizer can make improvements to the
IL. If you take advantage of C++-specific constructs and patterns, these
gains can be larger. But remember that /clr:safe code can¡¯t use native
classes or memory, and so your existing code won¡¯t recompile to safe.
/clr:pure code mixes traditional native classes and managed classes in the
same image, but with ¡°CLR-style defaults¡±. It¡¯s appdomain friendly, and
can benefit from some of the same optimization opportunities as above. Some
traditional code can be recompiled to pure, but pure mode is missing some
things (__stdcall, for example) that stop some libraries you might want to
use (ATL, MFC) from working. This can limit its utility. Calling down to
traditional native library functions (printf, strcpy, etc) involves
thunking as usual.
/clr code mixes traditional native classes and managed classes in the same
image, but with ¡°native-style¡± defaults. It is the only one of these
models that can link in existing native libraries and other native code not
compiled /clr. It is not appdomain friendly (in general), and suffers from
thunking costs in some areas. Thunking was improved a bunch in Whidbey, but
working with /clr code performance is still quite subtle. /clr code can
perform very well, but is likely to require more tuning than the two above.
And there is a tension between the CLR and the native models that comes up
a lot. Since things like vtable slots are native function pointers by
default, you can get a lot of thunking in some scenarios.

Depending on your scenario, you might want to choose one or another of
these models. If you have lots of existing code, you probably need /clr
right now, but this is the one with the most challenges. Our recommendation
in general is for customers to take a large application and recompile
specific files /clr rather than throw /clr on the whole application. This
path is easier to work with in general. And only the source files that need
to work with managed objects or call managed APIs need to be /clr.

Also /CLR is the only option when compiling MFC code. NGEN will not help
with thunking issues, it just saves you JIT'ing costs.
You may start with this sample:
http://www.microsoft.com/downloads/details.aspx?familyid=987021bc-e575-4fe3-
baa9-15aa50b0f599&displaylang=en
It isolates managed code into an extension DLL.

Best regards,

Peter Huang

Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.