[fpc-devel] Performance of string handling in trunk
mschnell at lumino.de
Fri Jun 21 08:59:15 CEST 2013
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel