[fpc-devel] Proof of Concept ARC implementation

[Hans-Peter Diettrich]

Sven Barth schrieb:
> On 28.10.2014 10:15, Michael Schnell wrote:
>> On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote:
>>>
>>> Something like ShortString and AnsiString?
>>>
>> Only that ShortStrings can easily be avoided (AFAIK, no great
>> performance advantage to use them) and hence are seldom used right now.
> 
> ShortStrings don't have implicit initialization/finalization, thus no 
> implicit try/finally blocks, which at least with FPC's platform 
> independant exception handling mechanism or SEH on i386-win32 have quite 
> some performance impact even in case no error occured (SEH on 
> x86_64-win64 (and in theory arm-wince) only has an impact in case of an 
> error (and an impact in binary size for the exception tables)). Also 
> there is no reference counting for ShortString.
> 
> So: basically the performance of reference counted objects compared to 
> normal objects is more or less similar to the performance of AnsiStrings 
> compared to ShortStrings (it's not completely equal, because AnsiStrings 
> are allocated on the heap while ShortStrings are on the stack, but it's 
> good enough...). And did anyone yet complain about the performance of 
> AnsiStrings? ;)

Right, this entire discussion is somewhat fruitless without benchmarks.

I wonder how difficult it would be to implement the existing Interface 
refcounting model for TObject, so that this runtime variation could be 
tested and benchmarked as well, in addition to the current compiletime 
approach. According to the problems of the compiletime approach, 
revealed in this thread, it looks not viable to me at all.


Just an idea about type incompatibilities:
When a TArcObject cannot be assigned to a TObject variable, because a 
conversion (as between ShortString and AnsiString) is impossible, then a 
delegate could be created that turns the TArcObject into something 
compatible with TObject. I have no idea how this could be 
accomplished[1], but as long as it only affects refcounted objects, the 
overhead has to be accepted when using ARC objects at all. Some overhead 
is inevitable for ARC, and everybody should be free to decide whether 
such overhead is acceptable for his projects or targets. Not using ARC 
at all should always be an option.

[1] Perhaps the same (possibly simplified) mechanism could be used, for 
TArcObjct/TObject conversion, as for Interface/TObject conversion.

DoDi