mschnell at lumino.de
Mon Jul 1 10:27:08 CEST 2013
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.
More information about the fpc-devel