[fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
I am trying to EnumerateFiles (create a list of all files that match a given filespec) across and down a whole drive. I've directly used the EnumerateFiles code from TurboPower's SysTools as available on SourceForge. The code works just as TurboPower designed and it and my wrapper code runs find on some drives but fails miserably on the very one that I would like to use the code on. As the EnumerateFiles code attempts to append one more filename to the Tstrings, it throws an exception and dies from lack of memory. The trouble is not in the memory used by the Tstrings to hold the list of found files but, rather, in the way that memory fragmentation occurs during the FindFirst(), FindNext() and FindClose() calls. This can be verified by eliminating the storage of anything in the Tstrings list at all. The routine will still die and in the same place and at the same filename. The error is not from a lack of stack space, either. The error is EOutOfMemory that indicates a less easily solved problem. Can anyone recommend a method to search a whole drive, of arbitrary size, without running out of memory. Stu Cox ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question on how to avoid memory trouble using 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@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] New stylesheet for fpcunit xml reports
Hi, Dean Zobec created a new xmlreportwriter for fpcunit. Among others it supports nested test suites. Does anybody have a stylesheet for showing such a report. Maybe somebody is willing to create one. Examples of the old xml format+ style sheet (slightly modified): http://www.hu.freepascal.org/lazarus/testresults/monitor.xml Example of the new xml format: http://www.hu.freepascal.org/lazarus/testresults/results.xml Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] Question on how to avoid memory troubleusing FindFirst(), FindNext() and FindClose()
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
