Optimizing performance: Calling C routines from VB

[pixelate]

Greetings.

My question is with regard to performance optimization with respect to calling routines in a C DLL from a VB6 application. I have created a small C DLL that includes math functions that take advantage of bit shifting in C. To test the performance of the C routines, I setup a loop that cycles N times, each time through the loop I call a C routine of interest.

Here is the nutty part: If I run a timing test out of the VB Run-time environment, I am able to call a function, ABC (written in C), in ~8 seconds (for the N cycles). Then, I build an EXE (actually, an SCR) from the VB. I run this and the same cycling takes ~9.5 seconds. Can anyone offer an explanation, and better still, what I can do to make the performance of the EXE match that of the VB run-time environment?

Notes:
1. The DLL is ~40 K, compiled with Speed Optimization, no MFC.
2. The DLL contains ~10 routines.
3. N = 1,000,000.

Thoughts & more questions:
1. Does the order of the routines in the .DEF file have an impact?
2. Would using the routine's Ordinal position in the VB Declare have a benefit?
3. Is there some tool / method that can be used to build the C DLL into the VB built EXE?

Thanks much in advance.

[HarryW]

Was the VB executable compiled with optimisations? I can't think of any other reason for it being slower.

I'm not sure if you can link into static libraries with VB, but I expect so. In that case you could compile the C library as a static library (*.lib) instead of a dynamic link library (*.dll), which would save some initial linking at least. I'm not sure if it makes a difference to the speed once the dynamic link is established.

[jim mcnamara]

Harry is right - you need to see how you compiled your VB code.

Some thoughts --

You have to remember that you're in a multi-programming, multi-tasking envronment, so the kernel or some other task may be doing something while you code is running, and it screws up your performance metrics. For example, if the kernel decides to write something to the page file just once during your run, your results are seriously skewed. Or you can spell 'skewed' another way if you like.

Also, during measuring performance you need to account for instantiation of the class - before you go measuring stuff. The class 'connection' is already there in the IDE. Ie., use the math functions at least one time, then start your timer on a million operations. Then compare this to native VB operators and see who wins, if a comparison is warranted.

[pixelate]

Hello again.
In reply to Harry and Jim:
1. I compiled the VB with all optimizations.
2. I ran a battery of timing tests, the first always costing more time. After several tests, the times settle with ~2% variation.

After more testing, I found to significant difference when:
1. I reduced the DLL to just the 3 critical routines.
2. Used the Ordinal position to access the API from VB.
3. Built the DLL with 4 vs 8 byte Struct boundary.
4. Built the DLL with __fastcall, __stdcall, __cdecl*.

If you have further suggestions, I would be glad to hear from you.

Another question: is there a method for bit shifting in VB (other than dividing by 2^N or multiplying by a reciprocal)?

Cheers.

[HarryW]

VB doesn't do bit shifts unfortunately

[jim mcnamara]

Hehehe -

VB is shiftless, you mean.