If you call into a virtual function that happens to be defined in a DLL, then there is NO DIFFERENCE compared to a virtual function that happens to be defined in the EXE. Now, calling a virtual function is a little bit more expensive than calling a non-virtual function, but if you're already using interfaces, pure abstract bases, and all that good stuff, then DLLs don't add any extra cost at runtime. (It's exactly the same cycles -- the caller doesn't know whether he'll end up in a DLL or an EXE)

Quote:Original post by doynax

Quote:Original post by chollida1
Agreed with teh link time comment, but this speed up comes at the cost of startup time on your app. ie if you statically link your app will start faster as the loader doesn't need to load the dll into memory and then match up the exe's imports with the dll's exports.

True, but it's still a lot faster than the full linking procedure especially when optimizing at link time.
And instead of having to jump all over the place fixing up single calls, importing a DLL simply consits of fixing a few entries in a separate import table. So there's no need load the whole program.

Perhaps this is true, that's debatable:). In my area of work we try to push the processing into offline work so that the runtime of the program will be faster.

At Corel when we split our code out into many dll's we noticed taht it loaded slower that statically linked libs. This was evident even with rebasing:)

Cheers
Chris