[fpc-devel] type discussion

[Danny Milosavljevic]

Hi,

Am Samstag, den 04.06.2005, 16:02 +0100 schrieb Jamie McCracken:
> 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.

owner nil, and free later

> 
> 
> > Setting a reference to nil works automagically (user doesnt need to do
> > it).
> > Only remaining serious problem are reference cycles. And thats a BIG
> > problem (see old java versions and swing, and you will see... its the
> > horror).
> > 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)!

I dont know the fcl enough for that.

But generally speaking, most (nice) trees have that problem actually. 

TXMLNode
  Parent: TXMLNode
  Children: list(TXMLNode);

ref cycle:

a: TXMLNode;
b: TXMLNode;

a := TXMLNode.Create;
b := TXMLNode.Create;

a.Children.Add(b);
b.Parent := a;

not freeing anything:

a := nil;

not freeing anything:

b := nil;

not freeing anything:

a := nil;
b := nil;

> 
> 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.

For gui stuff, it like happens all the time... for tree stuff, it like
happens all the time ... hmm

> 
> 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 

and pascal strings are ?

> 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.

what is that ?

> 
> jamie.

cheers,
   Danny

-- 
www.keyserver.net key id A334AEA6

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20050604/04aa3aae/attachment.sig>