[fpc-pascal] Feature announcement: Dynamic array extensions

[Mark Morgan Lloyd]

On 07/06/18 10:45, Martok wrote:
>> What actually happens is that the memory is released back to the heap > (but *not* to the OS, at least on Linux), with the result that > concatenating elements will introduce a substantial hit particularly if > space for a new element allocated from the heap isn't contiguous.Writing a preallocating wrapper *where needed* for heavily grown arrays isfairly simple.
> The thing is: it's rarely worth it ;-)I recently did that for a wavefront mesh loader that appends vertices one-by-oneto an array, and for a scene with some 400k vertices, the difference was justsome milliseconds out of several seconds overall.Turns out the allocator usually finds a spot where the array doesn't need toactually be copied around for a while, and the pure bookkeeping of realloc isvery cheap.

The bit of code I was looking at was a mainframe emulator reading a tape 
to find the block positions, I was appending elements individually using 
a user-defined + and it wasn't exactly fast (resulting in a tape load 
time probably slower than the hardware would have had 60 years ago)... 
although obviously not as bad as Nitorami's suggestion that every 
concatenation would result in a syscall.

I'd been expecting that SetLength() would do the same as it does with a 
string, i.e. prune the valid range without releasing memory.

What I've done so far is only interim code and I've got lots of ways 
round it, but the reality check was useful :-)

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]