How much average performance hit (in cycles) one is to expect by moving a function to a DLL instead of having it directly linked into the executable?

Depends on your processor. Speaking on x86, anything PII and above, it should only be around 1 clock cycle. (So long as it''s compiled for PII and above. Compiled for 386, there might be a forced pipeline stall making it 2 cycles.)

Of course this only applies to calls to the DLL from the EXE or other DLL''s. Calls to DLL functions from functions within the same DLL have no additional overhead.

Though that''s in terms of only per-call instruction cycle count. Additionally there''s the load time overhead for loading DLLs. Also moving a function to a DLL increases the overall size of the binary mass making cache misses more likely.

A LOOOONG time ago, I would have given you a lot of crap about relocation tables.

Now, I''ll say this. When a DLL is loaded, it becomes part of the program. It''s mapped onto memory, so there''s no such thing as a "stall" during a DLL function call.

Hmm... sorry but I don''t agree with GayleSaver; moving a function to a DLL does slow things down. I was curious about this as well and therefore decided to made my own test program; I have written a simple function that takes two DWORD arguments and returns the difference. Then I call this function 99999999 times with pseudo-random arguments and measure the results with GetTickCount():

- When I execute the function from a DLL, I get around 1350ms;
- When I execute the function from within the program, I get around 1100ms;
- When I execute the function from within the program with the function defined as _inline, I get around 600ms.

From these results I think we can assume that 1) even if it''ll be barely noticeable in most (if not every) cases, calling a DLL function is slower than calling an internal function, and 2) because it doesn''t allow you to use optimization tricks such as _inline, so it can lead to a large difference in terms of performance.

But of course, that''s not something you have to care about if your function is anything longer than 30 lines

Lamtd what is the diffence between your "_inline" and the c++ "inline" keyword ??

Jonas Meyer Rasmussen
meyer@diku.dk

Here''s what MSDN says about that:

"The inline keyword is available only in C++. The __inline and __forceinline keywords are available in both C and C++. For compatibility with previous versions, _inline is a synonym for __inline."

So basically, inline is for C++ and _inline is for C, even though you can use it in C++ as well (I''m more of a C guy as you might have noticed ).

quote: Original post by Lamtd

Hmm... sorry but I don''t agree with GayleSaver; moving a function to a DLL does slow things down. I was curious about this as well and therefore decided to made my own test program; I have written a simple function that takes two DWORD arguments and returns the difference. Then I call this function 99999999 times with pseudo-random arguments and measure the results with GetTickCount():

I just have to ask: Why 99999999 times?

Gyzmo
=======================
Meddle not in the affairs of dragons for you are crunchy and go well with toast.

quote: Original post by Lamtd

Here''s what MSDN says about that:

"The inline keyword is available only in C++. The __inline and __forceinline keywords are available in both C and C++. For compatibility with previous versions, _inline is a synonym for __inline."

So basically, inline is for C++ and _inline is for C, even though you can use it in C++ as well (I''m more of a C guy as you might have noticed ).

VC++ 6 predates C99, the latest C standard, in which inline functions are allowed (and which use the inline keyword). VC++ used _inline as an extension for C programs.

Thanks for the prompt response to my question.

It seems that the hit would be ok for file and initialization operations but not for the ones that are repeated many times per frame.