[fpc-devel] RawString

[Michael Schnell]

On 06/29/2013 12:23 AM, Hans-Peter wrote:
> Michael Schnell schrieb:
>
>> 5) In DXE the TStringList (and supposedly TStrings) class  uses 
>> "String" as it's user interface, In Delphi, "String" is mapped to a 
>> Type that is strictly encoded as a (windowish) two-Byte Unicode Type. 
>> This results in a huge performance hit when using it with a (normal) 
>> string variable with another encoding type, as storing and retrieving 
>> results in a dual conversion.
>
> You forget that the "normal" string type is UnicodeString, making 
> *your* suggestion extremely slow.
>

I don't see what you mean. My suggestion only introduces a modification 
when the compiler creates code to assign a RawSAtring to a normal 
String. Here (unless multiple different String encoding types are used 
by the application programmer himself) some three assembler instructions 
are to be executed at runtime to determine whether or not the dynamic 
type of the RawString matches. In respect what is done internally within 
the TStrings decedent (say TStringList) this is neglectable.

Now of course the modified TSringList code itself might be slower.

In fact I did not examine in depth how the current "Unicode" 
implementation of TStringList is done. But of course it somehow stored 
the string content on the heap and does some pointer management. The 
only difference I see with the "new" implementation would be that the 
size of each element is not 2*Length ( as with fixed 2-Byte encoding) 
but (dynamic Code Length) * Length. This again only asks for some three 
additional assembler instruction when inserting and retrieving it . So 
no performance problem here.

But of course TStringlist provides several more features than just "add" 
and "get". This doing this implementation is a decent lot of work to do. 
Thus I do see a manpower problem rather than a performance problem.

-Michael