On 6/28/2019 3:07 PM, Ryan Joseph wrote:
On Jun 28, 2019, at 3:40 PM, Martok <list...@martoks-place.de> wrote:
So, I would expect (and FastMM has codepaths for that), that repeated
reallocations cause some form of "over-allocating" growth and most of the
individual "+1" reallocs will be essentially no-ops.
Interesting. How could we test this to see if it’s true?
From FastMM4's readme:
https://github.com/pleriche/FastMM4/blob/master/README.md
"Intelligent reallocations. Avoids slow memory move operations through
not performing unneccesary downsizes and by having a minimum percentage
block size growth factor when an in-place block upsize is not possible."
Allocations within certain ranges are all lumped together based on fixed
block sizes (e.g., 15-24 bytes allocations are all rounded up to 24
bytes). It both reduces fragmentation and helps with resize performance
(there is other resize-specific logic as well).
String allocations and performance factored heavily into the
benchmarking for the FastCode competition that lead to FastMM4. You
should do your own benchmarking vs the system allocator though, to see
if it provides an improvement, especially if you're doing extensive
multithreading. We've been using FastMM with FPC on macOS and Linux for
about 4 years now and are very happy with it.
--
Zoë Peterson
Scooter Software
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
