Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Trying to track down memory leak(s)
Message
 
 
À
26/09/2011 16:08:13
Information générale
Forum:
Visual FoxPro
Catégorie:
Problèmes
Versions des environnements
Visual FoxPro:
VFP 9 SP2
Divers
Thread ID:
01398453
Message ID:
01524764
Vues:
97
>>>You heard not only from Greg that StringToFile is suboptimal.
>>>
>>>>BTW, unless I did something wrong my tests are opposite:
>>>
>>>There is no reason to open and close in the loop if you use a special logging class.
>>
>>But in order to write into the file don't we need to open with exclusive access? I don't think strtofile keeps an exclusive access on the file.
>
>Basic need for logging is the put the info into a file as fast as possible without any other intrusion.
>From this it follows that your timing example is faulty for the base pattern.
>
>If you have the need to read this info *while* the process is running, this should be handled by a subclass
>or any other means implementing the different strategy.needed here.
>
>If you want to the log to show info from different processes, IMHO this calls for another subclass logging into a table -
>the mechansism for multi-user is defined, you can easyly add the needed process info and query for distinct process via SQL:
>
>As much of the needed functionality is similar,
>several minimally different classes are IMHO the best "grouping" for such functionality in vfp -
>in python it might be a module with one class picking the strategy to be monkeypatched -
>such a way of coding in vfp would be similar to binding some event methods to empty (quasy-interface) class.methods,
>which does not really make for clean and easy to follow code.
>
>regards
>
>thomas

I should be able to read and modify and delete log file while the process is running from Windows Explorer. With strtofile I can do that, with other suggested approaches I can not.

I reverted to original code and only implemented write_log changes. So far so good although 1000 haven't finished yet and the log file is already 12 MB.

Anyway, turned out another EZ application did have this line
this.cInvokeFullLog = space(0) and so the problem didn't happen in that application. I bet re-setting it in this dll will work as well without any changes I did. I'm actually running a new test now with 200 iterations. Too bad it's so verbose.
If it's not broken, fix it until it is.


My Blog
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform