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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
