• bearophile <bearophileHUGS lycos.com> Nov 18 2009
• Sean Kelly <sean invisibleduck.org> Nov 18 2009

bearophile <bearophileHUGS lycos.com> writes:

Can something similar be done to the D GC, that share the same problem?
http://bugs.python.org/issue4074

Bye,
bearophile

Sean Kelly <sean invisibleduck.org> writes:

bearophile Wrote:

 Can something similar be done to the D GC, that share the same problem?
 http://bugs.python.org/issue4074


Seems like that would require a generational GC?  If so, that pretty much means
a new GC.  If performance is an issue for a known allocation scheme, it may
also be worth calling GC.reserve() beforehand.  This will pre-allocate a bunch
of free memory within the GC and keep it from needing to collect, assuming
you're just growing your data pool.  In casual tests, if I simply looked at the
high-water mark for my app's memory usage and called GC.reserve() with that
number at the beginning of main() my app performance was double or better than
it was without the reserve() line.