Load DLL to memory and persist

[Skysnake]

This is relevant

Quote

Yes. Call LoadLibrary() on that DLL. That will increase the internal reference count. FreeLibrary() only unloads a DLL when its internal reference count drops to zero. If you LoadLibrary and never FreeLibrary, the DLL will be stuck in memory for the lifetime of your process.

If you're running into a situation where somebody is calling FreeLibrary() on your DLL and causing it to be removed from memory while you're still using it, you probably have a bug - a disagreement or misunderstanding about who owns the DLL and is responsible for releasing it. A bug that should be fixed rather than worked around by a LoadLibrary hack.

From here https://stackoverflow.com/questions/3454315/is-it-possible-to-pin-a-dll-in-memory-to-prevent-unloading

I use several UDFs on the Forum to do various things.  Those UDFs work very well.

Effectively the UDFs are DLL wrappers, that make it possible to access DLL functions easily without the long hard slog of DLLCall() every time.

However, I have now run into the issue that multiple UDF DLLCalls are slow. Not mind numbingly slow, but slow enough to become noticeable with a large of repeated function calls.

So I was wondering, is it possible to "load a DLL into memory" and leave it there for the duration of my script's lifetime, avoid repeated DLL on-disk reads with a persistent in memory DLL?

From Microsoft

https://docs.microsoft.com/en-us/windows/desktop/dlls/about-dynamic-link-libraries

Looks like what I want to do is: load-time dynamic linking,

So next question, (a) how do I do this with AutoIt (b) How would this impact on standard AutoIt type DLL calls?

 

The point is speed.  Is there a different approach?

Or am I barking up the wrong tree?

Skysnake

Edited March 28, 2019 by Skysnake

[Nine]

You could try to use the Func _WinAPI_GetModuleHandleEx with the flag $GET_MODULE_HANDLE_EX_FLAG_PIN.  I would be very interested to know the results ...

[Skysnake]

1 hour ago, Nine said:

_WinAPI_GetModuleHandleEx

 very interesting. I will need to mod the UDF to see what happens. Will try ... this is very new to me

[Skysnake]

err.number is:      0x80040154
    err.windescription: Class not registered

    err.description is:     
    err.source is:      
    err.helpfile is:    
    err.helpcontext is:     
    err.lastdllerror is:    0
    err.scriptline is:  797
    err.retcode is:     0x00000000

I simply replaced the DllOpen with the _WinAPI_GetModuleHandleEx

;$__hDll_QPDF = DllOpen($sDLLFile) ; handle to DLL 2019.03.28
$__hDll_QPDF =  _WinAPI_GetModuleHandleEx($sDLLFile, $GET_MODULE_HANDLE_EX_FLAG_PIN)

But this is obviously not the way to do it.  

Edited March 28, 2019 by Skysnake

[LarsJ]

Your DLLs will remain stored in memory as long as your script is running. The problems you experience when a large number of repetitive function calls become slow have nothing to do with the DLLs not being constantly stored in memory.

It's simply because AutoIt is an interpreted language that's not fast for a large number of repetitive tasks.

The only solution to this kind of bottleneck problems is to replace the critical parts of the code with true compiled code.

There are two ways you can do this in AutoIt. The absolute easiest way is to use C# or VB.NET code through the .NET framework.

The other way is to create your own DLL with a language capable of creating DLLs.