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

[Ivo Steinmann]

Graeme Geldenhuys schrieb:
> 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 -
>   

In the core of all windows nt systems, there's the NT API. The normal
WinAPI is on the top of the NTAPI. the NT API itself uses UTF-16 as
stringtype!

type
  UNICODE_STRING = record
    Length: USHORT;
    MaximumLength: USHORT;
    Buffer: PWSTR;
  end;

const
  FileShareMode = FILE_SHARE_READ or FILE_SHARE_WRITE or FILE_SHARE_DELETE;
var
  str: UNICODE_STRING;  { utf16 type from ntapi }
  attr: OBJECT_ATTRIBUTES;
  io: IO_STATUS_BLOCK;
  ntmode: Integer;
  Handle: longword;
begin
  attr.Length := sizeof(attr);
  attr.RootDirectory := 0;
  attr.Attributes := 0;
  attr.ObjectName := @str;
  attr.SecurityDescriptor := nil;
  attr.SecurityQualityOfService := nil;

  NtOpenFile(@Handle, ntmode, @attr, @io, FileShareMode,
FILE_NON_DIRECTORY_FILE or FILE_SYNCHRONOUS_IO_NONALERT)
end;



So in core, winnt is working with UTF16. All ANSI Winapi functions map
to these winnt calls.

-Ivo Steinmann