LIB vs EXE time difference (30 times slower)

[s196675m]

My GUI application called a function in a library (image processing library) but it takes 20 to 30 times more time to execute this function when comparing to the time required when calling standalone .exe file.

Both library and GUI compiled with managed c++ (pure:clr) and in the GUI there is a reference for the library as a additional dependencies in the linker input.

When I make .exe (using pure:MSIL) file instead of .lib and run from command line passing the required argument is just take one to one and half minute to execute it .

When I make the library file (bypassing the main function) from the same source code and calling the function from GUI takes arround 20 to 30 minutes. The source code for the library orginially written in C/C++ but I compiled it using manged c++ pure MSIL to match with the GUI.

Compilation and linking everything is fine and I can not find and explain the cause of 20 to 30 times slow running when library is used.

Is there anybody here in this forum help me or explain the possible cause of slow running.


Any idea, link, suggestion will be highly appreciated.
Thank you.

[darwen]

Are you doing a comparison in a debug build or a release build ? I'd suggest comparing the times when in a release build.

I do not understand what you mean here. What do you mean by 'produce a lib'. Do you mean produce a static lib i.e. link to a .lib file ?


My GUI application called a function in a library (image processing library) but it takes 20 to 30 times more time to execute this function when comparing to the time required when calling standalone .exe file.


In order to do timings you'll have to produce an exe which links to your library - so which two exe's are you comparing ? The above statement says that 'when I call the function from an exe it's taking 20 to 30 times more time to execute than when I call the function from an exe'. It doesn't make sense.

However it is possible that the translation from native to MSIL is causing a slowdown such as you describe. The native C++ library will be translated to its equivalent MSIL which will put heavy overheads on it if, for instance, it's doing a lot of indexing of arrays.

Consider the following :


const int myArrayLength = 3;
int myArray[] = { 2, 3, 4 };
int total = 0;

for (int index = 0; index < myArrayLength; ++index)
{
total += myArrayLength[index];
}


In a native C++ build there won't be any bounds checking in the indexing of the array. However in .NET there is which will put an overhead on the call and slow it down.

In addition to this the native C++ compiler optimises array access (and other things) far better than the equivalent MSIL compiler because it doesn't perform checking (bounds checking, type checking etc etc) at runtime.

So just 'flipping the managed flag' as Microsoft likes to call it is sufficient to get native C++ to compile to MSIL but can have severe performance drawbacks.

I'd suggest keeping native C++ seperate from .NET by creating a native dll which your .NET application interfaces with using p/invoke (look up platform invoke). This is the easiest solution.

You can mark sections of C++ as 'compile to native' by using the


#pragma managed(push)
#pragma managed(off)
// .. native C++ goes in here
#pragma managed(pop)


statements but this method is more complex than just creating a seperate native C++ dll which contains your library.

I always keep native code seperate from .NET code. If a piece of code, or library, has been written to compile to native I keep this in native by producing a native dll and use p/invoke to interface with it in .NET code. And this way I've never had any performance problems.

Darwen.