AutoHotkey Community

Sounds intimidating but should in fact be pretty easy and straighforward to implement. Here's a rough sketch: whenever there is a DLLCall() the C++ code should do a LoadLibrary() for the DLL in question, up to a maximum of say, three or four DLLs. When four DLLs are loaded and there is another call to DLLCall() with a fifth DLL, the first one loaded is freed and the fifth is loaded. Etc. In effect this means that the last three or four DLLs stay loaded.

This should make explicit LoadLibray() calls almost a thing of the past. Another advantage would be that this would automatically speed up all scripts that use DLLCall(), even if the author couldn't be bothered to call LoadLibrary() himself.

There may be very subtle side effects, but I think in general this "caching" should be no problem. However, if there are issues, perhaps a new function DLLCall2() could be used.

It's a good idea. The thing that bothers me about it is that all cached DLLs would stay in memory until the script exits, which probably increases memory usage (perhaps someone could test this on a largish DLL).

In addition, unless a new command were added to free the cached libraries, there would be no way to free them without exiting the script.

A good compromise might be to have a new option in the last parameter that specifies whether the DLL should stay cached until the script exits.

Thanks for suggesting it. More comments are welcome from anyone.

True. That shouldn't be much of a problem for scripts that do something and relatively quickly exit. But a script that runs all day (I have a few fairly large ones that run continually) might be a different story.

One solution could be to free these DLLs after a given period of time: if there have not been any DLLCall()s for say five minutes, they are freed. This of course would make the implementation more difficult.


That's probably the way to go. It is only half-automatic but this should be fine.

Nice. This makes automatic caching more attractive as the default behavior (perhaps this default could be overridden via option).

Although these are ingenious ideas, and although there is clearly a benefit to caching, I still have some doubt that it's worth the extra code size and documentation complexity. Opinions from anyone else would be welcome.

Since thomasl is going to include RegEx with the help of DLLCall. I assume it will make a big difference if the dll is cached.

I think an automatic freeing after a period of time is not neccessary. Only an option to free the memory. The coder has to specify this explicitly. This way, it is clean and saves AHK the code and docs.

_________________
Ciao
toralf

Couldn't this already be done in a script by using DllCall with FreeLibrary? Maybe I'm misunderstanding the end result but it sounds like a function and a timer would have the same result...

My interpretation is that the primary goal is to accelerate scripts that use DllCall yet do not call LoadLibrary and FreeLibrary. So it's a convenience feature that would boost performance without the script author having to worry about which DLLs need to be kept resident, and when to free them.

Your interpretation is correct. It would not cost much, be easy to do and is convenient. What more can one ask for?

I think DLLCall() is among the most underestimated features of AHK: instead of enlarging the core one should try to provide nice bindings to external stuff (ie DLLs). Almost everything has already been invented by someone else.