Riduzione dell'utilizzo della memoria con Symfony e il bridge PHPUnit

Question

A partire da Symfony 2.7, lo Symfony PHPUnit Bridge è stato creato come un ottimo modo per ottenere avvisi di ritiro dai test (vedere anche associated Symfony blog entry). Come parte di questo pacchetto, anche la garbage collection è stata disabilitata, il che sembra rendere l'ingombro di memoria di una grande suite di test fuori controllo.

Ad esempio, senza ponte:

Time: 5.01 minutes, Memory: 964.75Mb 

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

Lo stesso test suite con il ponte abilitato:

Time: 4.98 minutes, Memory: 3003.00Mb 

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

Remaining deprecation notices (9) 

Nella documentazione, si osserva che la rimozione di garbage collection durante il test è inteso a ridurre il verificarsi di errori di segmentazione in determinate condizioni, il che non è qualcosa che abbiamo ancora sperimentato.

Mi rendo conto che potremmo semplicemente riattivare la garbage collection nel nostro file di bootstrap PHPUnit specifico dell'applicazione, oppure potremmo anche rimuovere il bridge dal caricatore automatico e registrare manualmente solo il gestore di deprecazione. Sono più interessato, però, all'intento di questa inclusione (e veramente, forse tutto ciò che manca è una documentazione su come evitare questo comportamento).

A parte questo, c'è un cambiamento associato che dobbiamo apportare al modo in cui stiamo strutturando i nostri test per gestirlo? Questa è una suite di test che include molti test funzionali a stack completo e quant'altro. Sembra che l'esecuzione senza garbage collection possa rompere molte suite di test di grandi dimensioni, a meno che non mi manchi qualcosa.

Questo è sotto PHP 5.5.9, PHPUnit 4.7.7 e Symfony 2.7.3.

Answer 1

Il codice in cui viene girata la garbage collection menziona anche lo PHP bug that it is set to avoid. Non esiste alcun codice definitivo per far sì che il bug si mostri facilmente e in modo affidabile, e non è chiaro se versioni più recenti (nelle serie 5.6, e esp 7.0) siano immuni al problema.

La rotazione di gc, può anche velocizzare la velocità della corsa - esattamente per gli stessi motivi di ciò che è accaduto con Composer - la garbage collection può impiegare molto tempo.

Riattivarlo negli script di avvio, dopo che è stato disattivato nel bridge, potrebbe aiutare con la memoria.

Sarei più propenso a capire perché i test richiedono così tanta memoria: vedere quanta memoria è in uso prima e dopo i test e svuotare gli oggetti utilizzati nelle funzioni tearDown() potrebbe fare molto per cancellare la memoria.