https://issues.dlang.org/show_bug.cgi?id=15084
Issue ID: 15084 Summary: GC must ensure there is at least X% of free space in the heap after collection to avoid frequent collections Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: dmitry.o...@gmail.com One thing that any remotely production-quality GC does is analyze the result of collection with respect to minimal headroom - X % (typically 30-50%). If we freed Y % of heap where Y < X, then the GC should extend the heap so that it get within X % mark of free space in the extended heap. See the exchange in NG discussion at http://forum.dlang.org/thread/mailman.149.1442256696.22025.digitalmar...@puremagic.com On 14-Sep-2015 21:47, H. S. Teoh via Digitalmars-d wrote: > Over in the d.learn forum, somebody posted a question about poor > performance in a text-parsing program. After a bit of profiling I > discovered that reducing GC collection frequency (i.e., GC.disable() > then manually call GC.collect() at some interval) improved program > performance by about 20%. > ... On Monday, 14 September 2015 at 18:58:45 UTC, Adam D. Ruppe wrote: > Definitely. I think it hits a case where it is right at the edge of the line > and you are allocating a small amount. > > So it is like the limit is 1,000 bytes. You are at 980 and ask it to allocate > 30. So it runs a collection cycle, frees the 30 from the previous loop > iteration, then allocates it again... so the whole loop, it is on the edge > and runs very often. > > Of course, it has to scan everything to ensure it is safe to free those 30 > bytes so the GC then runs way out of proportion. > > Maybe we can make the GC detect this somehow and bump up the size. I don't > actually know the implementation that well though. --