[fpc-devel] TList slowness in classes

[Michael Van Canneyt]

On Fri, 24 Dec 2004, Mattias Gaertner wrote:

> On Fri, 24 Dec 2004 12:13:15 +0100 (W. Europe Standard Time)
> Michael Van Canneyt <michael.vancanneyt at wisa.be> wrote:
>
> > On Fri, 24 Dec 2004, Mattias Gaertner wrote:
> >[...]
> > > And creates the implicit exception frame only in RaiseIndexError.
> >
> > I have changed the procedure.
>
> Talking about TList slowness:
> In the last years TList and TStringList became slower and slower.
> Are there any alternatives in classes.pp? A simple TList providing only the very
> basics, less checks, no notifications, less virtuals, reordered IFs ... ?

TList has almost no virtuals, so I doubt you will find anything to
change there. The notifications can be optimized, Dean Zobec wanted to
try this. This is as far as I'm concerned the biggest showstopper.

If you want to make an ancestor, make it TAbstractList. But to make this
work, you'll need a virtual Get() method, which is more or less what you
wanted to avoid in the first place.

> If this TBaseList (or TSimpleList or TQuickList or THumbleList) would
> be the ancestor of TList, existing code could easily be improved - the
> user only needs to rename his TList to TBaseList.
> Or maybe give this base thing the correct name. I never understood,
> why Borland named it 'list'. AFAIK in computer science a list is a
> linked chain of elements. While TList is an dynamic array with some methods.

It is.

I suspect that TList is also often used in the wrong way. The basic
methods (get/set) are quite small and fast. Only the growing mechanism
is slow. People should set the capacity before adding anything to the
list. If you don't do this, then each N calls to add() will need to do a
reallocation of the whole list...

Michael.