[fpc-devel] Re: dominant short strings in compiler source

[Flávio Etrusco]

On 5/18/06, Пётр Косаревский с mail.ru <ppkk at mail.ru> wrote:
> L> Can someone tell me how slow/fast a dynamic array is compared to a fixed one? Say you used
> L> a dynamic array of chars or dynamic array of shortstrings - would the dynamic array be
> L> slow on a general basis? Maybe we will have to resort to benchmarks using the cpu timer.
> L> And then there is also a fixed array of shortstrings or a fixed array of chars too.
>
> Dynamic arrays are reference counted, but it does not slow a program
> much if you mostly read/modify them, but do not assign. With
> optimizations on it doesn't differ from common arrays in inner cycles.
>
> Some benchmarking some time ago (see maillist) didn't show anything
> clearly: dynamic arrays even appeared faster sometimes.
>
> But they were introduced for Delphi compatibility, so I don't find
> them very good: they always start from zero (a[0] in one-dimensional
> case), if you used static array as formal parameter (use array name) (e.g. for
> blockwrite), you have to use first element with dynamic arrays. As I
> wrote (today?) you may have to check manually that length of array is
> not zero (to avoid range check error or something worse), even if
> nothing would be tried to write to the array of zero length.
>
> So, generally developers don't like dynamic arrays, and I don't think
> that thet want to use them in compiler sources.

Dynamic arrays can be very handy and I never knew anyone who avoids
them. Of course if your array has fixed length there's no reason to
use a dynamic array either.
Fortunately it's no very often that one falls in Borland's trap that
dynamic arrays aren't copy-on-write like AnsiStrings... BTW, is this
the behaviour in FPC, too?

> Ansistrings are even worse. A simple program which did ONLY modify
> elements of ansistring, not modifying its length, improved 20% in
> speed (it did some things besides toying with that string) by turning
> ansistrings off.

It's simply because the code has to check there's only one reference
to the string on each change. If you know there's no concurrent access
to the string (e.g. you app is single-threaded, or you have a local
copy of the string) you should access it as a PChar.

> But they are said to be improved in recent versions (recent snapshots?).

I find it strange that the cost of copying a ShortString (maybe
because they are at most 255 bytes? Maybe cache locality usually is
fine in this case? 8-|   ) is lower(better) than the
locked-count-reference and the exception trapping...

Anyway, isn't it just the case to correctly optimize string parameters
as 'const' and 'var', and maybe using PChar in some few places, or can
you think of any other reason for AnsiStrings to be slower than
ShortStrings?

Cheers,
Flávio