Well I'm finally at that point with my 2D renderer that I'm satisfied with all it's features and wanted to start thinking about making it faster. It's all in a static lib so I was wandering would taking the trouble to implement it in a DLL instead result in greater performance?

Quote:Original post by Sneftel
First of all... actually, no. First of all, Have you profiled your renderer yet to determine where the bottlenecks are? Trying to optimize without profiling first is a little bit like painting racing stripes on your car to make it go faster. Second of all, no it won't.

thank you, and yes, I have been setting my profiler up into the renderer all day, but am still setting up a few test apps, to test different situations. I was just looking for the one answer for now, ill bug ya later with millions of questions on how to be optomize the rest.

DLL's are more of a construction feature than an optimization avenue in my experience. They allow you to construct robust, componentized and maintainable solutions - not faster ones.

If you're only interested in performance then I would put money on there being other more beneficial routes to explore.

btw, moved to 'General Programming' as I don't see this as being a DX-specific issue/question.


Cheers,
Jack

Quote:Original post by SnT2k
It may actually depend on the function itself and the linker you're using. If a specific function gets called a lot of times (when I mean a lot, I mean a LOT), the function call overhead may kill performance (however, it's no different compared to calling a function in your program). Linking statically MAY cause your linker to inline some function calls in your code, eliminating the overhead.

In anycase, if you're calling a function a lot of times (i.e. Texture::setPoint( x, y, color ) ), you're better off batching them which has a better chance of improving performance.

Yes, this is something to keep in mind. Your compiler/linker may decide to inline functions even if you did not explicitly mark function "inline". And modern compilers are able to inline functions at link-time from static libs. A DLL makes this impossible.
But, as SnT2k said, this will only be an issue if you have a LOT of calls made to the DLL that would otherwise be inlined.

The question is more "why are you asking this question?" than anything else (no offense intended). I guess that somebody either asked you the question or told you that one of theses is faster than the other one. There is no trivial answer to it, except this one: are you sure it really matters?

DLLs and static libraries are fundamentally the same thing. There are a few catches that you must be aware of (DLLs functions are called using an indirection table (rough cost: a jmp instruction (that's one or 2 clock cycles IIRC), they are very likely to be placed in a different memory page, which would lead to less efficient code cache management and so on) but on the other hand they also have some nice properties - they can reduce the code size, which might lead to a better code cache management.

So in the end, not only one cannot answer this question in the general way, but it may also question the question itself: since no generalities can be made, is the question that interesting? It shows an interest in mastering application performance, but does it do it in the right way? Instead of focusing on this particular problem, shouldn't one focus on the real performance problems in an application? (algorithm enhancement, implementation improvements and so on). Bad algorithms and implementation are responsible for 99% of your speed problems - while other, more obscure micro-optimizations will only give you 1% benefits.

For my part, I consider that while the question is interesting (it's quite a good question in fact) the answer is not really relevant. If profiling shows any difference between the two methods then you can make a choice (but be aware that any major change in the project might change the result of the profiling). If profiling don't show any real difference, chose the one that will allow you to manage your project.

Best regards,

Quote:Original post by Emmanuel Deloget
DLLs functions are called using an indirection table (rough cost: a jmp instruction (that's one or 2 clock cycles IIRC)

You'll have to forgive me for the nitpick, but for the sake of accuracy this isn't strictly true.

DLL functions are necessarily a level of indirection further away than statically linked functions, but only due to the IAT (import address table), which results in a CALL DWORD PTR[<IAT Entry>]. The JMP table you speak of is created by many compilers for the sake of edit-and-continue and suchlike. By directing all function calls through a JMP table, it's relatively simple for the debugger to compile a new function ad-hoc and reassign the jump. Some compilers have taken to leaving this table in for release builds, for reasons I'm uncertain of. Anyway, such JMP tables may be found in dynamic and static libraries alike, so it's not fair to give DLLs the blame [rolleyes].

But that's besides the point. Emmanuel and Sneftel speak the truth. It's good to hear that the OP is busy profiling and not painting go-faster stripes.

Admiral