You can clone with
RSpec.configure do |c|
c.gc_frequency = 10
This would allow GC to run after every 10th example, allowing the user to set tweak the frequency per needs of each suite.
As a part of this, is it possible to ensure that the scheduled GC run time doesn't get added to the execution time calculated for the last example that ran? That's what has turned me off from using this technique in the past since fast examples would be blamed for being slow when it was just the deferred GC execution, making the --profile significantly less useful.
@criego that would make this prohibitively complex in my view.
It shouldn't be a huge deal to just wrap the enable/start/disable calls in timestamp fetches, and accumulate (after-before) into a gc_time car that's subtracted from the total time and shown separately at the end, no?
@MrJoy - I'm skeptical. Feel free to offer up a patch and we can talk about it.
If the ruby runtime supports GC stats, that could be used.
Anybody care to submit a patch that adds this and solves for @cgriego's concern?
Working on this now. See pull request 561 as a precursor.
Also, regarding @criego's concern -- the whole point of this idea is that batch GC winds up being net faster in pretty much every case I can find. Batching is essentially trading off more memory usage for less CPU time usage.
Ok, patch provided. See pull request #561 for the full patch, plus fixes for a few warnings in your test suite.
In #653 it was decided that this should be a separate gem, which @MrJoy provides here: https://github.com/MrJoy/rspec-gc-control
This issue can be closed for now.