Optimization fun

[H. S. Teoh via Digitalmars-d]

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