Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Declare Penaly
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Fonctions Windows API
Titre:
Divers
Thread ID:
00692220
Message ID:
00692333
Vues:
23
Hi Troy,

>For example, If I had a function that needed to declare an API and that function was called frequently (perhaps in a loop); would it be better to make the declares and then clear the dlls within the function? Would repeatedly declaring a DLL without clearing that DLL cause a memory leak?

Let me start with the easy parts... No, declaring a DLL without clearing it before does not cause any memory leaks. I personally wouldn't clear a DLL declaration, because this only slows down the app. Now to the more difficult parts...

When you declare an API function using the WIN32API keyword, VFP does search its internal list of loaded libraries and doesn't attempt to load the library. It also looks up the function and would bring up an error when the function cannot be found. If you specify a DLL name, VFP calls Windows to load the library and only stores the declaration internally. It does not call the library to verify that the function does indeed exist. This happens when you call the API function.

The fastest is the declaration using WINAPI32 as the library name. Despite the fact that VFP has to lookup the function, it's by magnitudes faster. On my computer, DECLARE Beep in WIN32API Long takes about 0.01 ms which is the about same time that x=Space(20000) takes. When I replace WIN32API with the full path to KERNEL32.DLL, time goes up to 0.33 ms per declaration. Not specifying the full path, just KERNEL32.DLL, results in a major slowdown. The time to declare a single DLL function is now 6.47 ms, which is 64700% slower than the WIN32API declaration. The reason is that Windows locates KERNEL32.DLL by searching along the path in this case.

To summerize: With WIN32API I would always redeclare functions I need. The little overhead is well worth the increased security. With custom DLLs, though, you should be more careful and in any case provide the full path to the DLL.

Christof
--
Christof
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform