Reducing memory usage with Symfony and the PHPUnit bridge

Question

As of Symfony 2.7, the Symfony PHPUnit Bridge has been created as a great way of getting deprecation notices out of your tests (see the associated Symfony blog entry as well). As part of this package, garbage collection has been disabled as well, which seems to make the memory footprint of a large test suite spiral out of control.

For example, without the bridge:

Time: 5.01 minutes, Memory: 964.75Mb

OK, but incomplete, skipped, or risky tests! 
Tests: 1189, Assertions: 2380, Incomplete: 2.

And the same test suite with the bridge enabled:

Time: 4.98 minutes, Memory: 3003.00Mb

OK, but incomplete, skipped, or risky tests!
Tests: 1189, Assertions: 2380, Incomplete: 2.

Remaining deprecation notices (9)

In the documentation, it is noted that the removal of garbage collection during testing is intended to reduce the occurrence of segmentation faults under certain conditions, which is not something we've yet experienced.

I realize that we could simply re-enable garbage collection in our application-specific PHPUnit bootstrap file, or we could also remove the bridge from the auto-loader and manually register only the deprecation handler. I am more interested, though, in the intent behind this inclusion (and truly, maybe all that is missing is some documentation on how to avoid this behavior).

Aside from that, is there an associated change that we must make to the way we are structuring our tests in order to handle this? This is a test suite that includes many full-stack functional tests and whatnot. It seems like running without garbage collection could break many large test suites, unless I am missing something.

This is under PHP 5.5.9, PHPUnit 4.7.7, and Symfony 2.7.3.

Answer 1

The code where the garbage collection is turned also mentions the PHP bug that it is set to avoid. No definitive code exists to easily and reliably make the bug show itself, and it is not clear if more recent versions (in the 5.6, and esp 7.0 series) would be immune to the issue.

Turning of gc, may also speed the run - for exactly the same reasons as what happened with Composer: garbage collection can take a significant amount of time.

Turning it back on in your startup scripts, after it was turned off in the bridge might help with memory.

I would be more inclined to figure out why your tests take so much memory - seeing how much memory is in use before and after tests, and clearing down the objects used in the tearDown() functions could do a lot to clear memory.