For pre-Unicode versions of Delphi, the unique way of having UTF-16 native
type is to use the WideString
type.
This type, under Windows, matched the BSTR managed
type, as used by OLE and COM components.
In Delphi, WideString
implementation calls directly the
corresponding Windows API, and do not use the main Delphi heap manager.
Even if since Vista, this API did have a huge speed-up, it is still in practice
much slower than the regular string
type. Problems is not about
UTF-16 encoding, but about the memory allocation, which is shared among
processes, using the Windows global heap, and is much slower than our beloved
FastMM4.
Newer versions of Delphi (since Delphi 2009) feature a refactored
string
= UnicodeString
type, which relies on
FastMM4 and not the Windows API, and is much faster than
WideString
.
Within our mORMot framework,
we by-passed this limitation by using our RawUTF8
type, which is
UTF-8 encoded, so as Unicode ready as the new UnicodeString
type,
and pretty fast.
In a recent internal project, we had to use a lot of
WideString
instances, to support UTF-16 encoding in Delphi
7/2007, involving a lot of text.
It sounded to be very slow, so we had to do something!
This is where our new SynFastWideString unit comes in.
Purpose of this unit is to patch the system.pas
unit for older
versions of Delphi, so that WideString
memory allocation would use
FastMM4 instead of the slow BSTR Windows API.
It will speed up the WideString
process a lot, especially when a
lot of content is allocated, since FastMM4 is much more aggressive
than Windows' global heap and the BSTR slow API. It could be more than 50 times
faster, especially when releasing the used memory.
The WideString
implementation pattern does NOT feature Copy-On-Write, so is still
slower than the string UnicodeString
type as implemented since
Delphi 2009. This is the reason why this unit won't do anything on
Unicode versions of the compiler, since the new string type is to be
preferred there.