why is mscorwks.dll dominant in profile?

[Rewbs]

Hi,

I recently profiled my C# app with Intel's VTune.
A sample based profile revealed that over 50% of the clockticks are spent in mscorwrks.dll, executing mainly the following methods:

GetCompileInfo
CoInitializeCor
CoEEShutDownCOM
CorExeMain
DllGetClassObjectInternal

Does anyone know what these do or how I can find out?

I'd expect to see such overhead at the beginning of the run what with he CLR loading up and methods jitting etc... but this profile was made in the middle of a run after a rampup period.

Any input would be great!

Best regards,
Robin.

 

[chiph]

The mscorwks.dll is the core .NET assembly for a NT/2000/XP workstation. If you're writing a server app, I've heard that if you replace it (in your references) with mscorsvr.dll, you'll see a pretty good performance increase. Haven't tried this myself, just heard it somewhere.

Some of these methods sound like they're related to COM. Are you using any COM controls, or calling out to COM components? Do you have the "Register for COM Interop" option checked in the project properties? (this calls RegAsm for you to generate a .TLB).

Chip H.

 

[Rewbs]

Hi,
Thanks for your answer.

I'm not writing a server app, but I may try mscorsrv.dll instead to see what happens. I'm not using any COM components. However I'm not using Visual Studio .NET - do you know how I can disable "Register for COM Interop" from the command line?

Cheers,
Robin.

 

[chiph]

I don't see anything in the command-line switches for csc.exe regarding this. I think in the command-line environment, you're expected to create your own interop assemblies, and then explicitly link with / reference them.

Since it doesn't sound like you're doing this, that's probably not it. You might want to check the assemblies that you are referencing, to see if *they* use interop. For example, the OleDb database access assembly does interop.

Chip H.