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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel