[fpc-devel] Performance of string handling in trunk

[Michael Schnell]

On 06/25/2013 01:19 PM, Hans-Peter Diettrich wrote:
>
> This is not the case :-(
>
> A variable can not force a conversion, when a RawByteString is 
> assigned to it :-(
I suppose you decently tested this with the newest version of Delphi XE. 
I can't comment, as I dont have DXE. :-( .

But you and the docs state, that RawByteString is not intended to hold a 
string of unencoded raw bytes that never are supposed to represent 
printable characters, but despite of its name it is (e.g.) supposed to 
be used as formal parameter, a String holding printable characters with 
a known encoding is to be assigned to. Thus I in fact fail to see the 
sense of it existence, if really the information about the encoding type 
of the string, assigned (without conversion) to it, is lost.

OTOH it seems to be easily to understand and to implement that/if the 
dynamic EncodingTyp tag  (that according top the docs exists in the 
string management record together with the ContentPointer, the 
StringLength and ReferenceCounter) is updated with that information 
during the assignment (in the same way as ContentPointer and 
StringLength). This would allow for decent use of such a type variant 
and IMHO should be the way to go for fpc. This would be perfectly 
compatible, even if Delphi does not allow for such usage of the 
RawByteString Type. It would not slow down anything if you don't use 
that feature, and IMHO the performance hit would be close to zero (and 
still rather compatible) if implementing stuff like TStringList using 
this feature.

Effect:
  - Such a TStringList would be able to work with any String type 
without ever forcing an auto-conversion (unless you check out a string 
to a variable of a different (static) type).
  - Lazarus could use such a string type as it's interface to the user 
code. This would allow for using greatly the same code for multiple 
archs, independent of the user code. IMHO, the performance hit for this 
should be small, as these interface functions mostly are not used in 
very long close loops.

-Michael