[fpc-devel] RawString

Michael Schnell mschnell at lumino.de
Thu Jul 4 09:44:52 CEST 2013


On 07/01/2013 10:27 AM, Michael Schnell wrote:
> I don't see what you mean....
After some moire thinking....

Once the compiler should provide the appropriate support for RawString, 
I'd of course be happy to do a draft for a TStringList class based on 
RawString to do these store/retrieve performance tests.

My expectations for the results with Strings containing average German 
Text are something like this (the strings in the user code encoded so 
that no conversion is necessary):


8 Bit Strings in German ANSI code with the legacy 8 Bit TStringList 
object: _100_%_ (as a reference)

UTF-8 coded (old) 8 bit Strings with the legacy 8 Bit TStringList object 
(current Lazarus Programs are done that way) : _105_%_ (due to increases 
size of the string content)

UTF-8 coded (new) 8 bit Strings with a (never to be released) strictly 
UTF-8 coded  TStringList object: _106_%_ (due to the increased size of 
the String Record)

UTF-8 coded (new) 8 bit Strings with a RawString based TStringList 
object: _107_%_ (due to calculating the size of the elements to be 
stored by multiplying with the code size)

UTF-16 coded (new) 16 bit Strings with a strictly UTF16 coded 
TStringList object: _ 150_%_ (due to doubled size of the string content)

UTF-16 coded (new) 16 bit Strings with a RawString based TStringList 
object: _151_%_ (due to calculating the size of the elements to be 
stored by multiplying with the code size)


and of course:

UTF-8 coded (new) 8 bit Strings with a strictly UTF-16 coded TStringList 
object (seemingly the planned implementation when used in Linux when 
data is read from a "normal" file): _500_%_ (due to the necessary 
conversions).

-Michael



More information about the fpc-devel mailing list