> You can finalize it, so that it releases all private resources. That's > common practice in a GC environment. But then you are responsible when > the interfaced object is referenced from one of the still remaining > references, and it fails to act properly due to the missing resources.
I wish I could use an interface exactly how I could use an object (create..try..finally..free). But that it's another topic. > > Anyway, why you're saying that refcount is slow? Do you have any > > benchmark? > > > > If I recall you mentioned try..finally as the bottleneck, but AFAIK > > modern cpu should do it almost with zero overhead, differently from > > try..except. > > Please separate the overhead in normal operation from the overhead in > exception handling. I agree, but the ratio between try..finally without and with raised exception is something about 10000/1, and often an exception break the loop anyway. IMHO from a performance pov only try..finally without exception matters. At least if you're not Chad! (pun to the author of Indy ;))) > We had a lengthy thread about exception handling in > a Delphi group there's one on Borland groups years ago, too. > In normal operation a Try block requires to push and pop some pointers, > comparable to the argument handling of a subroutine call. The invocation > of the Finally code may cost a few extra cycles, because it has to be > executable both in normal and abnormal program flow. The Exception code > executes only when an exception occurs, so it does not add any time > penalty in normal operation. Consequently one should eliminate chances > for exceptions, not try/except/finally blocks ;-) My experiences and that lengthy discussion differs here: in delphi try ... finally ... end; is almost negible, without exception raised at least. I've no data here but with or without the block the time is quite the same. try ... except ...end; instead is really really really slow. with kylix the times were a bit higher but restoring after a exception was faster. I want to crono fpc now! ;)) Bye Uberto _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
