[fpc-devel] Is calling the Windows Unicode APIs really faster than the ANSI API's?

Graeme Geldenhuys graemeg.lists at gmail.com
Fri Sep 26 09:04:06 CEST 2008


On Thu, Sep 25, 2008 at 10:33 PM, Florian Klaempfl
<florian at freepascal.org> wrote:
>
> Who says that? UTF-16 is simply chosen because it has features (supporting
> all characters basically) ANSI doesn't?

Sorry, my message was unclear and I got somewhat mixed up between ANSI
and UTF-8. I meant the encoding type of String or UnicodeString being
UTF-16 instead of UTF-8.  The CodeGear newsgroups are full of people
saying that UTF-16 was chosen because they could call the 'W' api's
without needing a conversion.

My question is, has anybody actually seen the speed difference (actual
timing results) showing UTF-16 string calling 'W' api's compared to
UTF-8->UTF-16 and then calling the 'W' api's.  With today's computers,
I can't imagine that there would be a "significant speed loss" using
such conversions. The speed difference might be milliseconds, but
that's not really "significant speed loss" is it?

So has anybody actually done a timing comparision? Do you have your
test code available? Do you have your results published? I'm
interested to see the timing results using different hardware.

I suppose it would be viable doing timing results for saving text
files as well. After all, 99% of the time, text files are stored in
UTF-8. So in D2009 you would first have to convert UTF-16 to UTF-8 and
then save. And the opposite when reading, plus checking for the byte
order marker.  If you used UTF-8 for the String encoding no
conversions are required and no byte order marker checks needed.

Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/



More information about the fpc-devel mailing list