On 5/18/06, Пётр Косаревский с mail.ru <[EMAIL PROTECTED]> 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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
