Will there be any performance issue using C++ inside C#?
I have a C++ program which does text processing on 40k records. We developed this program in C++ because we thought it would be faster. Then I used/executed this C++ part inside my C# program using the process-execute but the probl开发者_JAVA技巧em is we feel like we lost control of the execution flow: not able to debug the C++ part. I want to integrate the C++ much more in my C# program. I googled and found that I have to generate a DLL for my C++ and then i can use it inside my C# program.
Question:
- Will this slow down the execution of the C++ part?
- Is there any other better alternative to integrate the C++ part inside my c# program?
You have a few options here:
Write the processing in .NET and measure the performance. If it is unacceptable try to optimize it. If it is still too slow you revert to unmanaged code. But thinking that unmanaged code will be faster and for this reason writing unmanaged code without measuring IMHO is wrong approach.
As you already wrote unmanaged code you can expose it as a dynamic link library by exporting a function that will do the processing:
extern "C" __declspec(dllexport) int DoProcessing(int);
Next you import the function in managed code:
class Program { [DllImport("mylibrary.dll")] static extern int DoProcessing(int input); static void Main() { int result = DoProcessing(123); } }
This works if the input and output of your processing is not very complex and can be easily marshaled. It will have very little overhead.
Compile the unmanaged code using C++ CLI as managed assembly and reference it directly.
Wrapping C++ code inside DLL will not slow it down in any way.
Yes there is a (slight) performance penalty for calling functions in DLL as opposed in the executable - for instance the compiler cannot inline calls. But this often is completely negligible overhead (3-5 CPU instructions)
This is probably the simplest way.
You can't tell if this will be fast enough to meet your goals without measuring. Do it the simplest way possible (wrap the existing C++ code inside a DLL) and see if it meets your performance goals. I'm guessing it probably will.
Calling native code from managed does have some overhead per each method call - if your program is heavily compute bound and will be calling the native methods many times per record, you may see a slow-down due to the interop. If your code calls the native code once to process all 40k records in bulk, the cost of doing interop will be greatly dwarfed by the actual time spent processing the records. If the records are coming from a slower storage media, such as over the network, your processing time will probably be negligible compared to the I/O time.
Try to implement it in C#.
40k records seems like a VERY low number. It may be (depending on how much processing you need to do on each record) that processing the 40k records in C# is actually faster than even spawning the process like you currently do.
Other that that compile your C app to a dll and load that in-process. That will still have some overhead, but it will be WAY smaller than spawning an additional process
I agree with AdamRalph - I do not think you gained anything but integration pains by writing this code in CPP.
BTW is CPP code managed? if it is why do not you just link it into your C# code and avoid all interop overhead
精彩评论