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

[ϸ�� ����������� � mail.ru]

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.


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.

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


If you talk of parameters etc, you should think of unicode strings
too. Tonow they are implemented so poorly, that I use static array of words
instead of widestring. The only advantage is ability to typecast to
pwidechar. And it is indeed array of words: no unicode specific tasks
may be performed.

Don't forget, that some Windows claim to support pathnames-filenames
in unicode up to 32000 characters long! (However, it does not work
both on user interface level and on api level. At least not as
expected. Maximum under winxpsp2 is ability to create
files/directories unreadable by user.) But it's only a matter of time:
probably Windows will become totally utf16 (not really unicode, but
at least utf16) really soon (at least in newer versions in a way
incompatible with current ones).


So, longstrings (shortintegerstrings?) sound more likely to be used by
FPK.