[fpc-devel] TList slowness in classes

[Dean Zobec]

> > 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.
unnecessary things have been added to TList to 
accomodate descendants (very bad OOP design decision IMHO), like the 
notification to be used in the only descendant, TObjectList, that transformed 
the Clear operation from an O(1) to an O(n) operation.
Here is what Delphi designer Danny Thorpe says about TList in his book Delphi 
component design (1997):
"You'll almost always wind up using a TList in a component, but you'll never 
create descendants of TList.  TList is a worker drone, not a promiscuous 
ancestor class."
Unfortunately the programmers of Delphi 5 seem not to have read his book :-)

another explanation from Danny:
"If you want to create a list of a particular kind of item and that list is 
used only in the private or protected sections of your component 
implementation, then just use a plain TList and typecast the list's raw 
pointers into the type you put into the list to begin with. 

If the list is exposed in the public interface of your component, typecasting 
is not an option.  You cannot require a component user to typecast a list 
item appropriately in order to access it.  You should create a simple wrapper 
class (derived from TObject, not TList) that exposes only the property and 
function equivalents of TList that you need and whose function and whose 
function return types and method parameter types match the type of data that 
the list contains. The wrapper class then contains a TList instance 
internally and uses that for actual storage."

So TObjectList should have been designed as a wrapper around TList, 
with no need to add the notification mechanisms in TList. 
I've began writing a tutorial for fpcunit and have chosen this refactoring of 
TList and TObjectList as a subject of unit testing for my tutorial.
Hope to finish it in the next two weeks.
>> Are there 
>> any alternatives in classes.pp? A simple TList providing only the very
>> basics, less checks, no notifications, less virtuals, reordered IFs ... ?
>> If this TBaseList (or TSimpleList or TQuickList or THumbleList) would be
>> the ancestor of TList, 
see above, composition  is a better solution then inheritance in this case 
IMHO
Ciao, Dean