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