[fpc-devel] Performance of string handling in trunk

[Hans-Peter Diettrich]

Michael Schnell schrieb:
> 
> On 06/20/2013 05:31 PM, luiz americo pereira camara wrote:
>> The point is that i would expect a smaller performance hit when 
>> there's no conversion going on. Something between 10% slower. In the 
>> cited case is more than 50% slow.
> As the "dynamic" types of (most) String Variables are already defined 
> and known at compile time, and thus (usually) the library does not need 
> to detect the encoding in realtime, the performance hit should be close 
> to zero, as long as the same String encoding is used as with the 
> non-(DXE-compatible)-Unicode project with the same source code.

Right. Even with RawByteString the test for same encoding should not 
take considerable time (compared with memory allocation...).

Different encodings require to convert both arguments into Unicode, and 
the result back into the target encoding.

> OTOH, if the former version used 1-Byte-Strings (ANSI or UTF-8) and the 
> new version used 16 or 32 bit Strings (UTF-16 or UTF32) I would expect a 
> severe performance hit as well because more bytes need to be moved and 
> because the cache gets a lot more tight because of the double memory usage.

Again I'd assume that the memory allocation for the result is the most 
expensive operation with UnicodeString operands, independent from string 
lengths.

DoDi