Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Current performance analysis shows that D3DXCreateEffect is called many times with different shaders. Between each call, the D3DCompile DLL is being loaded and unloaded. Is there an easy way to keep that DLL loaded, i.e. by holding a CComPtr to some resource or something similar?

share|improve this question
The DLL can be loaded using "LoadLibrary" function, although this is not a permanent solution as the name of the DLL is not guaranteed to always be the same. However, the actual DLL load time turned out to be negligible. – pauld Mar 21 '13 at 17:59
up vote 1 down vote accepted

What about just loading the DLL yourself using LoadLibrary and then calling FreeLibrary when you are done? From my understanding this will prevent the DLL from actually loading when anything else calls LoadLibrary on it so long as you are loading the exact same dll.

Per MSDN: The system maintains a per-process reference count on all loaded modules. Calling LoadLibrary increments the reference count.

share|improve this answer
yeah, this worked, but don't really want to depend on the DLL name, since this could technically change (maybe?). Using this, we discovered that performance of DLL loading was indeed negligible. – pauld Mar 21 '13 at 22:51
@pauld Since this is tagged DirecX9 and DX9 development has ceased I'd say you are fine and it will never change. – NtscCobalt Mar 22 '13 at 14:39

Honest answer - this isn't a performance problem - loading and unloading DLLs is something that Windows does on an extremely regular basis. You don't need to worry about it, unless you're calling it at runtime (in which case you have a design problem rather than a performance problem that you must solve).

You're much better off focussing your energies on things that actually are problems.

share|improve this answer
I disagree. Our design is such that we have to compile shaders at runtime. And with COM, you can keep DLLs loaded as long as you have a pointer to something that was created by that DLL. – pauld Mar 20 '13 at 14:56
I'd suggest revisiting that part of your design. That aside - the actual compilation time (especially if it's a large and/or moderately complex .fx file) will likely dwarf the DLL load/unload time. – Le Comte du Merde-fou Mar 20 '13 at 18:18
Different platforms/hardware should be handled once only at load time. There are other solutions for the user input issue, such as setting shader constants that then adjust a calculation result. What I'm saying is - be absolutely certain that you have this requirement before committing to it. – Le Comte du Merde-fou Mar 21 '13 at 19:29
Sorry, I guess by run-time i meant load-time (as opposed to a precompiled blob that is loaded from disk). The load time is slow and that is what needs to speed up. – pauld Mar 21 '13 at 23:08
The precompiled blob is platform-independent. Effects just wraps the native API, which uses one of the D3DXCompileShader* functions to make the platform-independent pre-compiled blob, then IDirect3DDevice9::Create(Vertex|Pixel)Shader to convert that to a platform-dependent shader. I believe that the ID3DXEffectCompiler interface also exposes this process, so that may be worth looking at too. – Le Comte du Merde-fou Mar 22 '13 at 0:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.