Subject | Re: [IBO] IBO - IB_String vs AnsiString |
---|---|
Author | m. Th. |
Post date | 2009-04-08T05:51:59Z |
Carlos H. Cantu wrote:
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.
profiler for Delphi it seems that it's Eric Grange's located (finally)
at http://delphitools.info
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.
http://www.deltics.co.nz/blog/?p=375
Thanks for the link, anyway.
m. Th.
> I'm still not using D2009, but I remember to have read in several...Perhaps it's better to make things clearer. The compiler, by itself,
> 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.
>
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 forYes. Sure. But first let's stabilize the beast. The standard sampling
> performance problems, specially in critical areas of the IBO code.
> Maybe using a profiling tool can help to identify bottlenecks.
>
>
profiler for Delphi it seems that it's Eric Grange's located (finally)
at http://delphitools.info
> Basicly, what I mean is: changing Strings to Ansistring, at first, mayYes. And not only in performance terms. The Unicode feature is stripped
> 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.
>
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 www.delphifeeds.com may lead into several blog postsJolyon made a mistake there. The correct conclusions are at
> regarding D2009 migration regarding strings details. Look, for
> example, http://www.deltics.co.nz/blog/?p=349
http://www.deltics.co.nz/blog/?p=375
Thanks for the link, anyway.
m. Th.