#pragma unmanaged

[Guest]

Hi,

I am working on a mixed native/managed project involving DirectShow and am
trying to decide how the modules should be partitioned. I am trying to
understand the true affect of #pragma unmanaged in a managed project. From my
research it seems that, assuming there are no managed/native thunks involved,
the code should perform as though it were compiled in a native Win32 project.


However, as a simple test, I created a project that builds a simple graph
and does some limited frame processing using a sample grabber. I put #pragma
unmanaged at the top of *every* file and compiled it as a managed project.
With the /clr switch there is dramatic performance degradation. With no
managed code at all in this project, I don't understand why. Do the COM calls
in unmanaged code still go through Interop?

Any explanation/insight would be appriciated.

 

[Rodrigo Corral [MVP]]

Here http://msdn.microsoft.com/msdnmag/issues/05/01/CQA/, Paul DiLascia
described a method to ensure which parts of your application compiles as
managed and which as native.

Here http://msdn.microsoft.com/msdnmag/issues/05/01/COptimizations/, there
is information about how to get the best perfomance when calling native code
from managed. Read the section titled 'Native and Managed Code in a Single
Image'

--
Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org

 

[Guest]

Thanks for the references. I had read Kang's "Power your app..." article.
The primary tip is avoiding or minimizing thunking - especially double
thunking. Given that there are no managed calls in my app and all code is
compiled under #pragma unmanaged directives, I would not expect any thunking
to occur.

Paul's article has some good tips on how to omit modules from being /clr
compiled, which I'm sure I'll use, but I'm still confused about the true
affect of #pragma unmanaged when compiled with /clr.

If all of my code is compiled under that directive and there are is
absolutely no managed code in the project, shouldn't performance be close to
native? I got an email response from a person that suggested several C++
optimizations are disabled when compiled with /clr. But the performance
difference is substantial - more than I would attribute to optimizations, or
lack thereof.

Thanks for your help. I'm not trying to be stubborn - just trying to
understand.

- Troy

 

[Guest]

Thanks for the references. I had read Kang's "Power your app..." article.
The primary tip is avoiding or minimizing thunking - especially double
thunking. Given that there are no managed calls in my app and all code is
compiled under #pragma unmanaged directives, I would not expect any thunking
to occur.

Paul's article has some good tips on how to omit modules from being /clr
compiled, which I'm sure I'll use, but I'm still confused about the true
affect of #pragma unmanaged when compiled with /clr.

If all of my code is compiled under that directive and there are is
absolutely no managed code in the project, shouldn't performance be close to
native? I got an email response from a person that suggested several C++
optimizations are disabled when compiled with /clr. But the performance
difference is substantial - more than I would attribute to optimizations, or
lack thereof.

Thanks for your help. I'm not trying to be stubborn - just trying to
understand.

- Troy

 

[Guest]

Sorry for the double-post. The site errored out on me and I thought it
didn't take the first one.

I sort of figured out my performance problem. I was using AtlTrace to send
frame counts to the debug output window. That was the performance killer.
It seems that when a project is compiled managed, the debug output goes
through managed objects, even for unmanaged code such as AtlTrace. (This is
just a guess, but the only conclusion I can draw.)

The good news is once that trace call was removed the performance was nearly
identical with or without the /clr switch.

Thanks, again, for your response Rodrigo.

- Troy