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 .dll 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With