[fpc-pascal] Question on how to avoid memory troubleusing FindFirst(), FindNext() and FindClose()
Cox, Stuart TRAN:EX
Stuart.Cox at gov.bc.ca
Sat Feb 3 00:57:51 CET 2007
Thanks for taking the time to offer help.
I don't believe that the memory is being used up by the TStringList
since I eliminated it from being populated at all. Through the whole
run of examining the drive's directories it never gets given a file.
Yet, memory is still completely used up.
Seems instead to be consumed by FindFirst and its friends. TurboPower's
EnumerateFiles uses FindClose appropriately but I'll examine it closely.
I'll work some more to try to isolate what's happening.
Stu Cox
-----Original Message-----
From: fpc-pascal-bounces at lists.freepascal.org
[mailto:fpc-pascal-bounces at lists.freepascal.org] On Behalf Of Marco van
de Voort
Sent: Fri, February 2, 2007 1:24 PM
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Question on how to avoid memory troubleusing
FindFirst(), FindNext() and FindClose()
> Can anyone recommend a method to search a whole drive, of arbitrary
> size, without running out of memory.
I don't know seen SysTools, but I worked analysing logfiles for a year.
All containertypes (TList TObjectList and TstringList included) that
have a single array as internal datastructure become prone to
fragmentation or slowdowns when the number of elements get bigger.
A rule of thumb border is 50k-500k elements.
So a simple plan would be:
- analyse what functionality is really used of TStringlist, since there
is a
lot of functionality there.
- Take a more scalable containertype and graft it into SysTools.
- Avoid TStringList in own code, or at least mark such code in
documentation and memory as scalability risk :-)
_______________________________________________
fpc-pascal maillist - fpc-pascal at lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
More information about the fpc-pascal
mailing list