Dynamic paths in CLFN

[orko]

On one of our large projects, I'm converting all of our Call Library Function Nodes to accept dynamic paths to the same DLL - which may reside in different places on the user's computer after installation. We're pulling an installation path from the install out of the Windows registry and appending the DLL name to it, then passing this into the CLFN as opposed to having the path hardcoded like it has been.

I haven't been able to find much info about the performance hit (if any) dynamically building these paths will cause in an application that may be calling this DLL in multiple threads at semi-reasonable (20Hz+) rates. Does anyone have experience with measuring this? I want to compare results, as my initial testing showed negligible difference...which surprised me.

Sorry if the above isn't clear. I'm just trying to get a firm (but be gentle) grasp on what is happening "under the hood".

[Rolf Kalbermatter]

QUOTE (orko @ Apr 18 2008, 05:54 PM)

On one of our large projects, I'm converting all of our Call Library Function Nodes to accept dynamic paths to the same DLL - which may reside in different places on the user's computer after installation. We're pulling an installation path from the install out of the Windows registry and appending the DLL name to it, then passing this into the CLFN as opposed to having the path hardcoded like it has been.

I haven't been able to find much info about the performance hit (if any) dynamically building these paths will cause in an application that may be calling this DLL in multiple threads at semi-reasonable (20Hz+) rates. Does anyone have experience with measuring this? I want to compare results, as my initial testing showed negligible difference...which surprised me.

Sorry if the above isn't clear. I'm just trying to get a firm (but be gentle) grasp on what is happening "under the hood".

I can't say how this is implemented for real but if I had to do it I would use some sort of caching algorithme in the Call Library itself. This would mean that I would maintain the last used path (initialized to NULL on load) and compare the new path with this path. If they match just call the function and otherwise unload the old library (Windows keeps a refcount) and load the new DLL and link to the function.

So there will be some overhead to compare the paths but that should be almost neglible. Loading and unloading a DLL costs definitly more performance although typically it is probably already loaded by other Call Library Nodes so that this overhead is also not so big.

Rolf Kalbermatter

[orko]

Thanks for your insight, rolf.

There definitely is some sort of comparison check so that the DLL isn't loaded/unloaded with each call, which I would expect from using the hard-coded path method in the Call Library Function Node. I was pleasantly surprised to find that there may be the same checking going on when you pass the path dynamically into the CLFN. That makes sense though that the path comparison would probably be done inside the node itself, since the compiler would be working overtime to try and figure out if all of the paths to each DLL were dynamically resulting in the same path.

FYI, some preliminary testing showed that there was ~40msec increase in delay by using dynamically built paths to a simple DLL "get value" call over 500,000 iterations. I can live with that! :thumbup: