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?
\$\begingroup\$
\$\endgroup\$
1
-
\$\begingroup\$ 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. \$\endgroup\$– defaultMar 21, 2013 at 17:59
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
2
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.
answered Mar 21, 2013 at 22:44
-
\$\begingroup\$ 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. \$\endgroup\$– defaultMar 21, 2013 at 22:51
-
\$\begingroup\$ @pauld Since this is tagged DirecX9 and DX9 development has ceased I'd say you are fine and it will never change. \$\endgroup\$ Mar 22, 2013 at 14:39
\$\begingroup\$
\$\endgroup\$
5
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.
answered Mar 20, 2013 at 14:45
-
\$\begingroup\$ 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. \$\endgroup\$– defaultMar 20, 2013 at 14:56
-
\$\begingroup\$ 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. \$\endgroup\$ Mar 20, 2013 at 18:18
-
\$\begingroup\$ 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. \$\endgroup\$ Mar 21, 2013 at 19:29
-
\$\begingroup\$ 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. \$\endgroup\$– defaultMar 21, 2013 at 23:08
-
1\$\begingroup\$ 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. \$\endgroup\$ Mar 22, 2013 at 0:44