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