You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
minor symfony#16798 [Process] Unset callback after stop to free memory (Slamdunk)
This PR was submitted for the master branch but it was merged into the 2.3 branch instead (closessymfony#16798).
Discussion
----------
[Process] Unset callback after stop to free memory
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
As of yet, a `Process` instance can't free memory.
The built-in callback has a self-reference to the intance not cleared after instance destruction.
I've tried to change both `buildCallback` and https://github.com/symfony/process/blob/v2.7.6/Process.php#L1373 usage to avoid self-referencing, but it can't be done without breaking BC, and the memory issue is still there.
A simple test script (that obiously can't be embedded in unit-tests)
```php
for ($inc = 0; $inc < 10000; $inc++) {
$process = new Symfony\Component\Process\Process('echo 1');
$process->mustRun();
$process->stop();
unset($process);
echo (memory_get_usage(true) / 1000000) . ' MB ' . $inc . PHP_EOL;
}
```
Before:
```
1.572864 MB 0
5.505024 MB 9999
```
After:
```
1.572864 MB 0
1.572864 MB 9999
```
Ok, in this simple scenario 4 MB of RAM is nothing, but in our business app full of IOC where `unset`-ting is hard, our RAM explodes.
After `stop()`, the callback is no longer necessary.
To be clear, the garbage collector in the previous example was already active.
Deactivating it manually, which somewhere is needed to avoid particluar segfaults, obiously leads to worse scenarios:
Before:
```
gc_disable();
1.572864 MB 0
29.360128 MB 9999
```
After:
```
gc_disable();
1.572864 MB 0
1.572864 MB 9999
```
Commits
-------
ec93b9a [Process] Unset callback after stop to free memory
0 commit comments