Skip to content

Remove useless code #57868

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

Merged
merged 1 commit into from
Aug 12, 2024
Merged

Conversation

alexandre-daubois
Copy link
Member

@alexandre-daubois alexandre-daubois commented Jul 29, 2024

Q A
Branch? 7.2
Bug fix? no
New feature? no
Deprecations? no
Issues -
License MIT

I went through the remaining components and bundles, following my last PRs of this kind.

Copy link
Member

@jderusse jderusse left a comment

Choose a reason for hiding this comment

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

Did you use a tool that automates the changes? If yes, I think the tool has a bug regarding variable changes in try/finally blocs

@alexandre-daubois alexandre-daubois force-pushed the more-useless-code branch 2 times, most recently from 1b48b57 to 3258a9e Compare July 29, 2024 13:14
Copy link
Member

@fabpot fabpot left a comment

Choose a reason for hiding this comment

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

I've started to review the PR, but I'm wondering if these changes are really worth it.

@alexandre-daubois
Copy link
Member Author

alexandre-daubois commented Aug 3, 2024

I'd say yes for a the following reasons:

  • Removed casts are either not needed or delegated to the engine which will do it faster
  • A strong dependency to Clock is removed from a bridge because it actually doesn't need it
  • Many local variables are inlined which saves some useless allocations
  • Some private functions and constructors have parameters that are not used at all anywhere and can be removed entirely without consequence
  • In some places, exceptions are immediately thrown after being catch which adds a bit of complexity for no gain
  • There is also an example of a @var that doesn't point to an existing variable
  • A few other things in the same vibe, but above are the main changes

Overall, it is a few optimization here and there and also a cleaner code with less "abandoned" method parameters and local variables that were maybe useful at some point but not anymore.

Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

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

All those .= or += are perf optimizations. Not using them means creating new values in memory instead of mutating existing ones in place.

You can try the following script to confirm (replace the call to f2 by f1 and vice-versa):

function f1 () {
    $a = str_repeat('-', 100000000);

    return $a . $a;
}


function f2 () {
    $a = str_repeat('-', 100000000);

    return $a .= $a;
}

echo memory_get_peak_usage();
echo "\n";
f2();
echo memory_get_peak_usage();
echo "\n";

@alexandre-daubois alexandre-daubois force-pushed the more-useless-code branch 2 times, most recently from bb9e2c7 to 0a2f748 Compare August 7, 2024 09:29

return $str;
Copy link
Member

Choose a reason for hiding this comment

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

should be reverted

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh alright, I missed the exact point of "All those .= or += are perf optimizations.". Should be good now, I also reverted all casters

Copy link
Member

@wouterj wouterj Aug 8, 2024

Choose a reason for hiding this comment

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

It's very debatable if we need such a perf optimization in a test class in my opinion. There are thousands of concatenating operators in the Symfony code base that don't do it in-place.

To be honest, all of the ones you commented on do not look like to me they are on the critical path of performance: it's either dev tools (browserkit, vardumper) or actions that are not in a critical path (the impersonator url generator might be the only one that we can argue might be called on every request).

Do we really need to keep all of them for added cognitive complexity?

Copy link
Member

Choose a reason for hiding this comment

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

CS shouldn't be a reason to degrade perf (var-dumper is perf-critical, everybody wants fast dumps). That's also not worth the future merge conflicts. I don't see any upsides that outweighs the downsides.

@nicolas-grekas
Copy link
Member

Thank you @alexandre-daubois.

@nicolas-grekas nicolas-grekas merged commit dd9fa15 into symfony:7.2 Aug 12, 2024
9 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants