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 [EMAIL PROTECTED] 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
