>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
This is exactly the kind of thing my string class wo
-pascal] Question on how to avoid memory trouble
>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
I think that its great that the hornet's nest that I stirred up might
mean that a new unit of container classes gets written...
...My trouble remains...
Getting a better containers unit is nice, but the root of the problem
seems to be the memory manager. Delphi's old memory manager had
fragm
Wayne Sherman wrote:
> Getting a better containers unit is nice, but the root of the problem
> seems to be the memory manager. Delphi's old memory manager had
No.
> fragmentation issues also. That is why NexusMM, BucketMM and FastMM we
The memory manager cannot fix fragmentation in TStringList
At 23:39 5-2-2007, you wrote:
I think that its great that the hornet's nest that I stirred up might
mean that a new unit of container classes gets written...
...My trouble remains...
Getting a better containers unit is nice, but the root of the
problem seems to be the memory manager. Delphi's
> >FastMM is open source, has anyone ported it to FPC?
>
> There are users that have got FastMM working with FPC. But
> it is not needed. The standard FPC heap manager is for
> single-threaded applications as fast as FastMM.
A little bit shortsighted (IMHO),as "everyone seriously concern
Helmut Hartl schrieb:
>
> > >FastMM is open source, has anyone ported it to FPC?
> >
> > There are users that have got FastMM working with FPC. But
> > it is not needed. The standard FPC heap manager is for
> > single-threaded applications as fast as FastMM.
>
> A little bit shortsighted
Florian Klaempfl wrote:
Helmut Hartl schrieb:
> >FastMM is open source, has anyone ported it to FPC?
>
> There are users that have got FastMM working with FPC. But
> it is not needed. The standard FPC heap manager is for
> single-threaded applications as fast as FastMM.
A little bit
On 12 Feb 2007, at 20:27, George Lober wrote:
One nice side benefit of FastMM is that it automatically lets you
know of memory leaks with no fuss and bother on the programmers part.
FPC has support for that built in. Just compile your application with
-ghl (that also does a lot of other me
>Florian Klaempfl schrieb:
> Well, the lockless multithreaded memory managers are a myth.
> Atomic exchange operations take a also a lot of time and are
> locked by the cpu as well.
>
The XEN Developers at Cambridge have nice papers to read ...
http://www.cl.cam.ac.uk/~kaf24/
(Others are
Helmut Hartl schreef:
http://www.research.ibm.com/people/m/michael/pldi-2004.pdf
This one is not lock free, because it uses atomic instructions used by
the cpu, which are essentially fine grained locks.
Vincent
___
fpc-pascal maillist - fpc-pas
Jonas Maebe wrote:
On 12 Feb 2007, at 20:27, George Lober wrote:
One nice side benefit of FastMM is that it automatically lets you
know of memory leaks with no fuss and bother on the programmers part.
FPC has support for that built in. Just compile your application with
-ghl (that also does
Vincent Snijders schrieb:
> Helmut Hartl schreef:
>
>> http://www.research.ibm.com/people/m/michael/pldi-2004.pdf
>>
>
> This one is not lock free, because it uses atomic instructions used by
> the cpu, which are essentially fine grained locks.
Exactly, and cmpxchg etc. are really expensive too.
> >
> > This one is not lock free, because it uses atomic
> instructions used by
> > the cpu, which are essentially fine grained locks.
>
> Exactly, and cmpxchg etc. are really expensive too. Since
> the original FPC heap uses already several pools, it should
> be easily possible to m
On 13 feb 2007, at 13:12, Helmut Hartl wrote:
Exactly, and cmpxchg etc. are really expensive too. Since
the original FPC heap uses already several pools, it should
be easily possible to make it scale better in multi threaded
applications.
Fine that sounds really nice - Do you already have a i
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
> 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 be
On Fri, 2 Feb 2007, Marco van de Voort wrote:
> > 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 incl
> On Fri, 2 Feb 2007, Marco van de Voort wrote:
>
> > > 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 Tstr
On Sat, 3 Feb 2007, Marco van de Voort wrote:
> > On Fri, 2 Feb 2007, Marco van de Voort wrote:
> >
> > > > 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 f
Am Freitag, den 02.02.2007, 08:52 -0800 schrieb Cox, Stuart TRAN:EX:
> 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.
>
>
> Yes it will, because the reallocations don't happen as often.
> The sorting introduces an overhead anyway, whether you set capacity or not.
Yes, but I was talking about slowness in general, not just from the heap.
And TStringList with those huge internal list has to move on avg half of the
arr
Am Samstag, den 03.02.2007, 16:36 +0100 schrieb Marc Santhoff:
> Am Freitag, den 02.02.2007, 08:52 -0800 schrieb Cox, Stuart TRAN:EX:
...
> > Can anyone recommend a method to search a whole drive, of arbitrary
> > size, without running out of memory.
>
> >From reading this thread I think you must
On Sat, 3 Feb 2007, Marco van de Voort wrote:
> > Yes it will, because the reallocations don't happen as often.
> > The sorting introduces an overhead anyway, whether you set capacity or not.
>
> Yes, but I was talking about slowness in general, not just from the heap.
>
> And TStringList wit
> On Sat, 3 Feb 2007, Marco van de Voort wrote:
>
> > > Yes it will, because the reallocations don't happen as often.
> > > The sorting introduces an overhead anyway, whether you set capacity or
> > > not.
> >
> > Yes, but I was talking about slowness in general, not just from the heap.
> >
>
Michael Van Canneyt wrote:
All this doesn't exclude that a specialized class may be more suitable for
the job.
To be honest, the only good point of TStringList seems to be that it is
default available on all Object Pascal. The specialised stuff (splitting
strings) is also plagued with odd
On Sat, 3 Feb 2007, Marco van de Voort wrote:
> > On Sat, 3 Feb 2007, Marco van de Voort wrote:
> >
> > > > Yes it will, because the reallocations don't happen as often.
> > > > The sorting introduces an overhead anyway, whether you set capacity or
> > > > not.
> > >
> > > Yes, but I was tal
27 matches
Mail list logo
