PGD - Some thoughts about the future

[User137]

@Andru
I totally agree with you about dynamic arrays. I mean which idiot though about idea that best solution to increase the size of dynamic array is to double it's size?
Imagine this: You have a byte array with 1024 items in it (using 1 KB of memory) and then you add just one item to it and it's size is doubled. Imagine that you have 1GB sized array and you add one new item. Utter stupidity..

Idiot you say... Now, i don't know how the arrays actually work, but lets assume like you say that dynamic array doubles it on power of 2 margins.

Imagine that you have [0..0] pointer array of size 1024 and you increase the size by 1 for 10 times in a row. Dynamic array makes only 1 memory allocation of 2kb, but pointer array makes reservation total over 10kb (1025, 1026...1034)! In addition to that, it's like a puzzle game in the memory - having odd sized memory blocks of random 1023, 1050 etc are harder to organize than if the blocks are evenly sized.
(Oh, what also happens on array resizing, is existing memory copied to new array. Again Setlength() would win by big margin.)

I haven't noticed much of a performance difference at all if you use dynamic arrays vs pointer arrays for texture memory. For most arrays you don't ever need to resize it, and when you do, dynamic arrays might win in performance. Previously i have known that TList follows the memory doubling method, but i am not sure about setlength(). And there are likely some limitations in higher amounts of memory, smaller reservations.

[code_glitch]

Imagine that you have [0..0] pointer array of size 1024 and you increase the size by 1 for 10 times in a row. Dynamic array makes only 1 memory allocation of 2kb, but pointer array makes reservation total over 10kb (1025, 1026...1034)! In addition to that, it's like a puzzle game in the memory - having odd sized memory blocks of random 1023, 1050 etc are harder to organize than if the blocks are evenly sized.
(Oh, what also happens on array resizing, is existing memory copied to new array. Again Setlength() would win by big margin.)

As an aside on this note, I'd be very interested in any tests/information anyone has on this. I use a lot of dynamic arrays that seem to behave themselves. My assumption is that its written that way to avoid causing memory fragmentation for memory sizes that scale linearly across all orders of magnitude (ie. there are x allocations done to get from 1KiB to 1MiB and another x allocations to get from 1MiB to 1GiB). I agree it could be better done. The question is what does it understand by 'allocate'? Is it allocating virtual, private or some other 'kind' of memory so that it has the memory needed/mapped/allocated but the OS can use it for other things until the array grows to that size?

[SilverWarior]

As an aside on this note, I'd be very interested in any tests/information anyone has on this.

Iztok Kacin is trying to create better dynamical array by slicing it into smaller pieces. You can read some info on this on his blog here: http://www.cromis.net/blog/2013/03/i...-sliced-array/
He also offers several comparion tests between his and regular dynamic arrays.

[SilverWarior]

Ups. I must admit that I have mixed arrays with Lists

[de_jean_7777]

Afaik dynamic arrays will only double in size only if you try to resize them. And it's existing size + new size. Resize will allocate new memory, copy over data and free the previous memory. In case the new size is smaller it is possible no reallocation will occur. Does not take up double memory, just the difference between new and old size, with a temporary need for additional memory while the array is reallocated. It does lead to memory fragmentation more easily. Also, the same will happen if you use a pointer to an array, and re-allocate the memory yourself. The same process happens, and dynamic arrays should not be that much slower than manual memory management. With dynamic arrays the compiler manages the memory and there is a small overhead (reference counting and what not). In any case, best to do as little resizing as possible. An idea for a benchmark.

[Andru]

Memory management is not a problem. There was something else... but now I can see only speed down when Range Check error is enabled(and this is normal). So, there is one more reason to update my engine ) And I changed my mind a bit about Pascal compilers But I didn't test 64-bit version yet, e.g. FPC generates more instructions when there is a code using dynamic arrays, maybe there was something not optimal for 64-bit.

update: Oh, now I remember, there were problems with throwing data via arrays between dll and application, and supporting C/C++. With time everything can be forgotten