Jonathan M Davis: > In any case, if you're looking to avoid GC collection cycles, it sounds like > std.gc.disable() and std.gc.enable() will help. But remember that that will > increase the odds that it will have to allocate more memory from the OS, > which > isn't cheap either. It's almost certainly cheap_er_, but it still wouldn't be > cheap. Also, with D's current GC, that means that your program will use more > memory overall.
>From my tests, the disable() is useful when you want to just build a data >structure, so when you need to quickly allocate many small parts, and then you >call enable() when the data structure is done. This avoids many possible >collections in the middle, and may lower the running time significantly. Recently the Python GC has introduces some similar automatic optimizations: http://docs.python.org/dev/whatsnew/2.7.html#optimizations The garbage collector now performs better for one common usage pattern: when many objects are being allocated without deallocating any of them. This would previously take quadratic time for garbage collection, but now the number of full garbage collections is reduced as the number of objects on the heap grows. The new logic only performs a full garbage collection pass when the middle generation has been collected 10 times and when the number of survivor objects from the middle generation exceeds 10% of the number of objects in the oldest generation. (Suggested by Martin von Löwis and implemented by Antoine Pitrou; issue http://bugs.python.org/issue4074 .) I don't know of something similar, may be done automatically by the current D GC. Bye, bearophile
