I agree, but indeed for a process like zipping in the range of MBs the load/unlod of a DLL is a small hit. It has more time cost if you'd connect and disconnect from a backend database between each query.
You can of course check allocated memory by SYS(1016). If you make tests at the command window notice in that window of the IDE VFP causes regular garbage collection, whereas you'd have to call SYS(1104) in your own code to trigger that. See Memory Management in
There are several documented and undocumented SYS functions about memory usage in the range SYS(1001) to SYS(1016).
foxpeert said:
All of these functions return varying values when executed in the Command Window, because the Command Window permanently enters the idle loop and therefore runs a garbage collection. Some functions filter on internally used handles, others don't do that. Nonetheless, these functions are good indicators for memory usage.
Which also means it's all a bit fuzzy and you don't get the immediate effect of RELEASE LIBRARY, so you get a blurry picture of memory usage with a lag that only becomes apparent after garbage collection, for eample. I don't find whether DLLs and FLLs fall into that VFP managed memory pool, but it would be strange, if not. There surely is more to get from Windows API functions, too.
One thing is obviously, though: The C/C++ code within an FLL can use VFP functions defined in winapims.lib that's shipped with VFP and linked when you build FLLs, but Craig Boyd might not have taken zlib source code and changed it to using VFP memory management, so that FLL gets memory more directly from Windows OS by malloc calls, reservicng process stack memory. That's not governed by VFP. Same is true for any API function, it's not so special, VFP simply has its internal memory management based on handles instead of addresses to support memory defragmentation with its own garbage collector.
I guess it can help to unload FLLs or DLLs therefore, not because of the memory they use up as themselves as code, that's surely still under VFP management, but because of the memory they allocate for themselves, ie for compression/decompression. That's where the remark comes from:
foxpert said:
Usually, you notice the stack in error conditions such as "insufficient stack space" or "Mismatched PUSHJMP/POPJMP call". Only C/C++ developers writing an FLL have to deal with the stack.
And when a DLL unloads (or an FLL, which mainly still is a DLL with some extras specifically to ease the usage from VFP in comparison to DECLARE, but loads and unloads with the same mechanisms), it's own memory allocations should be deallocated and thus you could say you only get doubtless memory deallocations by unloading an FLL. Well, if an FLL is written with the VFP API C++ functions it also really puts its own memory usage under the roof of VFPs own memory management. So you only can be sure if you know the FLL source code and should assume stack memory allocation from FLL and DLL functions that are underthe radar of VFP, although not under the radar of Windows. The C/C++ code would need to be messy to cause memory leaks especially when unloading.
I have used exactly that compression FLL without unloading in a system that zips often without issues, so the internal stack memory usage should be okay, just because it's not on VFPs own radar it isn't bad. The base project we talk of here is zlib:
And that's well maintained. While there are no FLL updates, the version Craig has used when building his FLL is still good to go, I don't suspect Win11 changed something in that respect, for example, you'd see it break immediately, if it breaks, as the main thing used of Windows is memory allocation, anything else is the compression/decompresion algorithms that are done within that memory, nothing Windows itself influences. So if memory allocation a la zlib 1.1.x or whichever version is within vfpcompression.fll is changed, it would stop working instead of degrading over time.
There's much caching done on files with hard and software and on the OS level, so to unload an FLL file put side to side with your EXE in the same appdir and then load it again should go fast. Not as fast as compressing a string in memory, but whenever you create new ZIP files that's surely the bottleneck as the initial writing of a file is always uncached file IO in comparisn to loading a DLL you already had loaded before.
I often added to an existing archive, so that would surely suffer from permanent unloading/reloading the FLL as it keeps forgetting what it had cached internally. If you do new files in every ZIP process it won't suffer from refreshing the FLL, but you also likely have no real problem you solve with this, as memory management still is okay not done with the VFP memory management. The only thing you gain is the memory of the FLL and what it cached for periods where you don't use the zipping functionality.
Observe and see which effect it has on performance and stability. I see Mike has written a short answer from experience and in the end that's what I know from this FLL, too. It cn be different with different FLLs. but in the majority of cases you don't have to deal with low RAM of a client, unless you apply a low limit to your own process with SYS(3050), which would be stepping on your own feet.
Chriss
