[fpc-devel] Performance of string handling in trunk

[Michael Schnell]

On 06/27/2013 12:26 PM, Marco van de Voort wrote:
>
> That already has been decided, everything Delphi compatible.
>
> I was just speaking hypothetic case.

The starting point of the discussion was the possibility to improve the 
compiler/library and potentially introduce mode settings that introduce 
a different (better) behavior. I don't suppose there is any 
documentation on fpc yet that exactly describes the behavior when 
assigning a RawByteString to a normal String (in DXE I did not see such 
documentation either)

> In general, it has been proven time and time again that deviating from 
> Delphi is nearly always the worse choice.
Here the deviation is just doing a decent implementation for a case that 
is depreciated and not decently defined in the Delphi docs, and for 
which a decent behavior can easily be defined and implemented.

> I don't think quirks mode would be useful. It is not just syntax, 

Yes, it is "just syntax" as what I suggest to implement in DXE just is a 
depreciated statement (e.g. myString := myRawByteString).

> In general the average code doesn't really honour such fine 
> differences, so in practice this doesn't matter.

This is very wrong IMHO.

It offers the possibility to create functions that can be fed with any 
(normal)  type of String and act on this without doing a conversion.

A prominent example is TStringList. I have no idea how it is implemented 
in DXE, but using "decent" RawByteStrings it can be implemented in a way 
that can be used with all strings without a severe  performance hit.

Another example is the Lazarus LCL that could provide a user interface 
done with RawByteStrings and thus allow for the user to use any encoding 
that is optimum for his application and LCL internally can use the 
string type that best matches the underling OS. The conversion - if 
necessary - would automatically be done at a decent point in the work. 
The performance hit would be minimal as the compiler only needs to 
implement any additional code (over using the same string type 
everywhere) when a normal String and a RawByteString get together in a 
single statement. Regarding that LCL calls are not done in close loops 
this would be close to zero.

-Michael