Am Dienstag, 4. Juni 2019 18:00 schrieb Martok: > Am 03.06.2019 um 14:49 schrieb Marco van de Voort: > > Note that it is fairly typical that also frustrated pre fastmm D7. > > Back then I wrote a simple pool-factory combo class for it, and > > with D2009 I upgraded it to generics,so that I can easily create > > pools for many such objects. > > Well, there is a general-purpose pooled allocator already. It's > called the heap manager ;-) > > Jokes aside, I did a bunch of counting. The only thing that sticks > around are 50kB TLazIntfImage instances. Everything else gets freed > right after processing. Just from the order of alloc/frees, there > shouldn't even be gaps, so I would expect the next iteration to just > find those allocations to be empty and reuse them. But for some > reason, that doesn't happen. > > I've compiled with FastMM for now, but it turns out this is in fact a > bit slower than the RTL MM, and I don't really trust my port yet...
Try compiling the heap manager with "-dBESTMATCH". This makes it a bit slower but greatly reduces fragmentation. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
