[fpc-devel] type discussion
jamie-junk at blueyonder.co.uk
Sat Jun 4 17:02:11 CEST 2005
Danny Milosavljevic wrote:
> I'd suggest creating tlist, tstringlist, tfilestream-like things with an
> optional owner (TComponent-like). I've been programming delphi for
> years, and trust me, I know how annoying keeping track of tlist memory
> is (and I mean _annoying like *@! hell_ :)). Of course having to cast
> around list content is even more annoying. But 'm trying to fix that
> now, in fpc.
you *might* have less overhead using ref count on a tstringlist then
making it a component (if you are creating more than one reference to it
or passing it as a parameter to a function then yes a component would be
more efficient). You also have the problem of what you are going to set
the owner to in the case where its only a temp variable.
> Setting a reference to nil works automagically (user doesnt need to do
> Only remaining serious problem are reference cycles. And thats a BIG
> problem (see old java versions and swing, and you will see... its the
> But it still 'only' means you have to set 'some' references to nil
> manually. Which is ugly. Either all or none would be cleaner :)
ref cycles are not a big deal - show me one bit of the FCL that has
cycles using Tobjects only (IE not with Tcomponents)!
Its obvious that you wont have cycles in things like TstringList,
TFileStream objects etc.
In fact only in Tlist are you likely to have cycles and in the add
method you could check to make sure no self references are added and
throw an exception if they are. A knowledgable developer can of course
set any object to nil if he knows that there are or likely to be cycles
but again this will only happen in a very small minoirty of cases.
I would implement ref count on TObjects with a protected boolean
variable to turn it off for TComponent descendants as we dont need to
ref count components and components by their nature are far more likely
to have cycles then plain objects.
Its also obvious that pascal by its nature is far better suited to
efficient ref counting than others like java because java strings are
objects and ref counting a whole load of short term objects can
adversely affect performance. (imagine deleting a stringlist where all
the strings are objects - you would have to call dec_ref on all the
strings and thats why ref counting is considered slow especially with java)
I am asserting that ref counting in pascal would probably have a much
lower effect on overall performance as a result. Ref counting objects
with long life spans is actually far more cpu efficient than any GC
scheme (and thats why the best performing GCs are hybrid GCs which
actually ref count globals and all objects that survive multiple
generations). In fact unless you are creating loads of temporary short
lived objects in your code, the overhead of ref counting should be
acceptable in most cases and of course you can optimise your code for
ref counting by using more global vars instead of temps/passing them as
parameters to functions etc.
But we cant test out any of this until we have c++ style exception
handling so its performance or lack of performance is just speculation
at the moment.
More information about the fpc-devel