After registering(RegAsm) my C# COM visible class, I see that CoCreateInstance(__uuidof(myclass)) takes a lot of time only for the first time, subsequent attempts in the same client process are resolved instantly. Any idea why is it taking time?
NGen is not an option for me.
My COM Server is in C# and client is in MFC/ATL
CComPtr<namespace::Imyclass> obj;
hrx = obj.CoCreateInstance(__uuidof(namespace::myclass));
The first call to CoCreateInstance has to load into the process, and initialize, the .NET runtime. Then, your DLL has to be loaded, "verified", and compiled into machine code (although just-in-time helps a lot to speed-up the startup). The .NET runtime also has to parse the metadata of your assembly, and then dynamically generate and compile the "COM callable wrappers" (http://msdn.microsoft.com/en-us/library/f07c8z1c.aspx) which are the proxies that bridge between the unmanaged COM world and the managed .NET runtime. Any additional libraries your code might use also needs to be loaded, verified and possibly compiled into machine code (if not NGEN'd).
This is inherently an expensive process. The delays you mention are not unheard of.
I don't believe there is much you can do to speed things up. I suggest you think about whether you can take the hit early in your program's lifetime by creating an object soon after startup. It won't make it faster, but it might improve the user experience dramatically. if your program just can't tolerate the delays, then you should not use .NET to write the COM object (more specifically, you should not use .NET in your process at all. This is not an issue with using COM; it's an issue with loading .NET)
Incidentally, this is one of the reasons why writing shell extensions in .NET is... "highly discouraged". See this recent post on this subject, which touches on the startup performance of .NET as well: http://blogs.msdn.com/b/oldnewthing/archive/2013/02/22/10396079.aspx
(That's why I asked earlier what kind of client you were running. A client that already runs .NET managed code depends on the .NET runtime and would not be affected by these delays)
The first call to CoCreateInstance is likely having to consult the registry and the file system, loading the appropriate code, allowing it to initialize, and finally invoke a factory to create the instance you've asked for (if it could be located).
The second call benefits hugely from these previous steps. If the first call was successful, then the code is already loaded and initialized, and all it has to do is invoke a factory a second time.
If this delay is only for first load (after computer start), then this is caused by loading all libraries. First delay after start (or after long time without usage of .NET) will always be slow. (See Micelli answer)
Delay can be also caused on each loading. Today I found out that internet connection can also cause the delay.
Measured values:
*non standard gateway: allowed TCP ports and connections are different for each computer (Different for WinXP and Win7).
Tested on Windows 7 (x64) and WinXP. I tested it because it came as a complain from a customer and located the delay to CoCreateInstance The loaded library is in c# and is signed (signed assembly with snk and with standard certificate for signing executable files).
