Subject Re: [IBO] IBO - IB_String vs AnsiString
Author m. Th.
Carlos H. Cantu wrote:
> I'm still not using D2009, but I remember to have read in several
> blogs that, in terms of performance, changing String to Ansistring is
> not good. Looks like the compiler has to do a lot of internal
> conversions any time you use AnsiString parameters with functions and
> procedures that are not specific designed for it.

...Perhaps it's better to make things clearer. The compiler, by itself,
doesn't do internal conversions. Yes, the new 'String' type is several
orders of magnitude faster than older 'WideString' which wasn't designed
for performance - it's goal is/was to behave like a BSTR COM type.

Also, we can say that _THEORETICALLY_ the 'AnsiString' is /faster/ than
'String' because of data size. 'String' occupies at least twice space in
memory compared with 'AnsiString'.

OTOH, the performance penalties about you've read come from Windows
itself which has Unicode calls only. The 'W' calls. All the 'A' calls
are converted internally (conversion which takes time) in 'W' calls. As
we know all Windows API was mapped in D2007 (and earlier) on 'A' callse.
So, we had in D2007 (& earlier):

[custom Delphi code] - calls -> DrawText - maps to -> DrawTextA -
conversion (NT core) -> DrawTextW [which is executed]

Now we have:

[custom Delphi code] - calls -> DrawText - maps to -> DrawTextW [which
is executed]

...which is way faster.

> So, my advice to Jason (and testers) is that you keep the eye open for
> performance problems, specially in critical areas of the IBO code.
> Maybe using a profiling tool can help to identify bottlenecks.

Yes. Sure. But first let's stabilize the beast. The standard sampling
profiler for Delphi it seems that it's Eric Grange's located (finally)

> Basicly, what I mean is: changing Strings to Ansistring, at first, may
> look like the easy and fastest way to make "old" code compatible with
> D2009, but regarding performance, it may not be the best thing to do.

Yes. And not only in performance terms. The Unicode feature is stripped
out. There are some solutions here. Jason opted to use overloaded
functions. I'll try to comment his solution as a reply to his post.

> A search in may lead into several blog posts
> regarding D2009 migration regarding strings details. Look, for
> example,
Jolyon made a mistake there. The correct conclusions are at
Thanks for the link, anyway.

m. Th.