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