Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[10.x] Fixes memory leak on anonymous migrations #46061

Closed
wants to merge 1 commit into from

Conversation

nunomaduro
Copy link
Member

This pull request fixes a memory leak on Laravel test suites that are using anonymous migrations.

// Work in progress.

// Before:
Time: 00:39.915, Memory: 324.00 MB

// After
Time: 00:37.882, Memory: 40.00 MB

Fixes #46029.

@@ -557,7 +568,9 @@ public function getMigrationFiles($paths)
public function requireFiles(array $files)
{
foreach ($files as $file) {
$this->files->requireOnce($file);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

static::$requiredMigrations[$file] ??= $this->files->requireOnce($file);

Try this instead of IF

@donnysim
Copy link
Contributor

I wonder if php will ever fix the anonymous global function memory leaking 🙃

@@ -557,7 +568,9 @@ public function getMigrationFiles($paths)
public function requireFiles(array $files)
{
foreach ($files as $file) {
$this->files->requireOnce($file);
if (! isset(static::$requiredMigrations[$file])) {
static::$requiredMigrations[$file] = $this->files->requireOnce($file);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remember correctly, require_once only returns true if the file was successfully required and does not return the return value of the file. That might be unintended at this stage

@dbohn
Copy link

dbohn commented Feb 10, 2023

Thank you for looking into this so quickly!
I noticed, that there is no logic in place to reset the state of the migration class. Is this intentional or still WIP?
This might be a breaking change (as there probably are devs relying on this when running their tests), which might be why it's targeted to v10 :-)

@rojtjo
Copy link
Contributor

rojtjo commented Feb 10, 2023

I noticed, that there is no logic in place to reset the state of the migration class. Is this intentional or still WIP?

This can be fixed by cloning the cached migration before returning it. I've tested this using your (@dbohn) example repository and the memory seems to remain the same.

This would mean that this pull request could actually target the 9.x branch.

// without clone
Time: 01:29.299, Memory: 38.00 MB

// with clone
Time: 01:29.864, Memory: 38.00 MB

@nunomaduro
Copy link
Member Author

@rojtjo Excellent idea. Going to update the pull request.

@nunomaduro
Copy link
Member Author

Replaced by #46073.

@nunomaduro nunomaduro closed this Feb 10, 2023
@driesvints driesvints deleted the fix/migration-memory-leak branch February 13, 2023 11:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants