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
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
