GetModuleHandle performance

Quick question:
I'm looking at an auto-generated header that looks like this:
1
2
3
4
int&   var1 = *(int *  )GetProcAddress( GetModuleHandle("myDLL.DLL"), "var1" );
float& var2 = *(float *)GetProcAddress( GetModuleHandle("myDLL.DLL"), "var2" );
int&   var3 = *(int *  )GetProcAddress( GetModuleHandle("myDLL.DLL"), "var3" );
// and then continues in this manner for another 1000 labels. 



I'm investigating why the program takes about 12 seconds longer-than-expected to start up and this is my first suspicion.

Do you think that I'll get a significant loadtime reduction if I modify the header generator to generate the following instead? I'm not sure if GetModuleHandle is a particularly fast or slow function call.
1
2
3
4
5
6
HMODULE hMyDLL = GetModuleHandle("myDLL.DLL");

int&   var1 = *(int *  )GetProcAddress( hMyDLL , "var1" );
float& var2 = *(float *)GetProcAddress( hMyDLL , "var2" );
int&   var3 = *(int *  )GetProcAddress( hMyDLL , "var3" );
//and then continues in this manner for another 1000 labels. 
Last edited on
The first option doesn't give you chance to check for failure, so I wouldn't consider doing it that way.
GetModuleHandle should be fast, as it retrieves the handle for an already loaded module. If it had been LoadLibrary() calls I would have been alarmed! But if you're worried, try timing the code.

If the whole lot is protected by code which checks that myDLL.DLL was successfully loaded, it should be safe when if comes to the repeated calls to GetModuleHandle. But I would use the single call to GetModuleHandle as it reads better to me.

I'm more concerned with the dereferencing of the memory addresses without checking their validity. Even this is what you want to do for the release build, I would expect some sort of debug validation to help with development.

You could alter that code generator so it creates code like

1
2
3
4
5
6
7
8
9
10
// utility header (not generated: used by generated code)

inline int& GetVarAddress_int( HMODULE hModule, LPCSTR lpVarName ) {
    static int dummy = 0;
    int *pvar = (int *)GetProcAddress( hModule, lpVarName );
    _ASSERTE( pvar != NULL ); // from crtdbg.h
    return ( pvar == NULL ) ? dummy : *pvar;
}

// Etc, for float and other required types 


then

1
2
3
4
5
6
7
HMODULE hMyDLL = GetModuleHandle("myDLL.DLL");
_ASSERTE( hMyDLL != NULL );

int&   var1 = GetVarAddress_int( hMyDLL , "var1" );
float& var2 = GetVarAddress_float( hMyDLL , "var2" );
int&   var3 = GetVarAddress_int( hMyDLL , "var3" );
//and then continues in this manner for another 1000 labels.  


And why are 1000+ variables are being accessed from a DLL? (are they all variables, or are some function).
Last edited on
Thanks for the replies.

They are all global variables. It's just how the model interface was designed by the company that is providing the DLL. It may not be the best, but I can't change it.

Since this DLL is similar to a physics model, if it doesn't load then the host software won't do anything useful anyways and will need to be restarted. The cabinets that run this software are designed specifically for it and we haven't had the DLL fail to load since we started using it two years ago. For those reasons I'm not really that concerned about the failure checking.

I'll look elsewhere for this delay, but thanks for the info. When we design another interface, I'll keep this in mind.
Topic archived. No new replies allowed.