Native c++ dll running slower when called from VB.net vs. running called from native .exe

I have some code in native C++ (Visual C++ 2010) to process a file of some GB. I compiled it to an .exe and it takes about 8 minutes. But I need to call it from a Visual Basic .net interface, so I put it in a .开发者_如何学Godll and created a c++/cli wrapper class to call my code in a native dll. The only interaction between the managed code and native dll is to call the function that initiates the processing. To my surprise the processing takes almost double the the time that takes the .exe way. I´m not really an expert in VB.net so maybe there are some settings or something to look at I don´t know. Any idea welcomed. Thanks in advance.

---

Couple of ideas:

• Maybe you built the .exe using the Release configuration, but the .dll was set to Debug. You sometimes see a big difference between release and debug builds, optimized code makes a huge difference.

• If your VB.net does anything besides calling the C++ code then it could be adding CPU load on top of what your .dll consumes. Any kind of background processing done on the VB.net side could account for the difference. To compare apples to apples you should have a command line VB.net app w/o GUI and with a single line that calls the dll function.

• If the above doesn't help I recommend that you create a native C++ app that links against this same DLL and compare this against the native exe version. If the C++ and DLL version performs the same as the C++ standalone exe then there's got to be something on the VB.net side that is consuming additional CPU. If, on the other side, the DLL is also slow when called from native C++ then you should look for differences in your build process for exe vs. dll, or for differences in macros/conditional compilations for exe vs. dll mode.

Good luck.

---

Does the C++/CLI wrapper really just call the DLL function, or does it load the DLL itself, then stick around and get managed by .NET? Is the native procedure getting its own thread, or a thread created in .NET's context? My gut is that .NET is doing something unnecessary to manage the lifetime of the object, the DLL, or the thread.

My suggestion is therefore to add an Event to indicate the DLL being finished with whatever it's doing, start a new thread from the native DLL to run the procedure, and return the event handle immediately. Have your .NET wait on that handle wherever it's appropriate.

---

Not really understand why the native dll called from DotNet side can double the processing time unless you can give more details.

However, if the native exe version works as expected, you can run the native exe as background process from the DotNet, passing api parameters via command line. You can even redirect the exe's console output to DotNet based GUI.

---

This is strange. I'ld look at all columns present in task manager and compare the both processes (working set size, page faults, ...). Then I'ld look at performance monitor and look into the cache manager values. Last but not least you could try only reading from files and not writing to see where the time is spent.

---

The .NET framework imposes some overhead in communicating from its "managed" code to native or "unmanaged" code. See here for some background.

So what you are seeing in performance terms is what I'd expect in general terms. If the native DLL were doing more work, I'd expect the communication overhead (efficiency penalty) to be a lower percentage.