On Fri, Nov 07, 2014 at 09:30:47AM -0800, H. S. Teoh via Digitalmars-d wrote: [...] > On another note, I wonder if reducing the frequency of GC collections > might help keep memory under control while minimizing the performance > hits. As a first stab, I could try to manually trigger a collection > every, say, 100,000 iterations of the main loop, which would be about > 10 or so collections per run, which should keep memory usage under > control while avoiding excessively frequent collections that degrade > performance. [...]
OK, I did a little test where I would disable the GC at the beginning of the program, then trigger a collection every 250,000 iterations. As a rough visual aid, I print a message before and after the collection so that I can gauge how long each collection is taking. It appears that as the program progresses, collections become longer -- expected, because the hash table is growing rapidly, so the marking phase probably would take longer (I didn't measure this in detail though). Overall, a puzzle that took ~7.0 seconds to solve now takes ~7.6 seconds, which is about 8% performance degradation. That's pretty high, considering that we already know that most of the new allocations between collections is live. Is there a way to tell the GC to ignore the hash table buckets for collection purposes? It would seem that most of the work is being wasted there since we already know it will be live until the end of the program. Another alternative is to manually call GC.free on reallocated arrays in the two places I've identified, and turn off collections completely. This could be a better approach in this case, since we already know where the reallocations happen. Another GC-related question: if the heap grows too large to fit in RAM, and a GC collection cycle is triggered, will this cause thrashing? -- since the GC will have to scan through all the blocks, causing *all* of them to be paged in and paged out again. Of course, this little side-exercise is more of a curiosity than anything else, since I'm planning to replace the hash table with something else that manually manages memory (and page to disk as necessary) anyway, so any optimizations along these lines will be moot. But it's interesting to explore how far one can go with the current system. T -- It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford
