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

Performance: remove unnecessary repeated function call #44545

Merged
merged 1 commit into from Oct 6, 2022

Conversation

jrfnl
Copy link
Member

@jrfnl jrfnl commented Sep 28, 2022

Why?

The length of the $existing_class does not change within the loop, so it is completely redundant and inefficient to recalculate the length for every loop.

Along the same lines, the count of $this->stack will not change within the loop.

How?

By making the function call once and saving the return value to a variable, we can avoid the unnecessary repeated function calls.

@github-actions github-actions bot added the First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository label Sep 28, 2022
@jrfnl jrfnl removed the First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository label Sep 28, 2022
@WordPress WordPress deleted a comment from github-actions bot Sep 28, 2022
Copy link
Contributor

@dmsnell dmsnell left a comment

Choose a reason for hiding this comment

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

hello again @jrfnl - did you measure any results with these changes or confirm that they make things faster or more efficient?

strlen() boils down to a property lookup, not a string-length computation, so the performance should be on par with storing it inside a variable. further, I would like to see any data suggesting that it's possible to measure the impact of this change; my own tests suggest otherwise.

for the case of the stack count in the block parser this patch introduces a breakage because $this->stack does change during every iteration of the while loop it's in. we need to confirm that a small refactor, even one that looks harmless, doesn't introduce a new behavior or defect into the code, and in this case all we need to do is look inside $this->add_block_from_stack(); to see it, as its first line mutates the stack.

@jrfnl
Copy link
Member Author

jrfnl commented Sep 28, 2022

hello again @jrfnl - did you measure any results with these changes or confirm that they make things faster or more efficient?

strlen() boils down to a property lookup, not a string-length computation, so the performance should be on par with storing it inside a variable. further, I would like to see any data suggesting that it's possible to measure the impact of this change; my own tests suggest otherwise.

I did not do any performance testing, but any kind of function call within a loop condition is generally speaking bad practice, no matter how small the impact may seem. It is also teaching devs bad code patterns.

for the case of the stack count in the block parser this patch introduces a breakage because $this->stack does change during every iteration of the while loop it's in. we need to confirm that a small refactor, even one that looks harmless, doesn't introduce a new behavior or defect into the code, and in this case all we need to do is look inside $this->add_block_from_stack(); to see it, as its first line mutates the stack.

Okay, so clearly I missed that, which does say something about how the code obfuscates what's going on, but that's another matter. I will remove that change from this PR.

The length of the `$existing_class` does not change within the loop, so it is completely redundant and inefficient to recalculate the length for every loop.
@jrfnl jrfnl force-pushed the QA/no-function-calls-in-loop-conditions branch from 1812942 to eb9f916 Compare September 28, 2022 22:12
Copy link
Contributor

@anton-vlasenko anton-vlasenko left a comment

Choose a reason for hiding this comment

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

Thanks for the PR, @jrfnl.
LGTM!

@anton-vlasenko
Copy link
Contributor

In my opinion, calling strlen() with each loop doesn't make sense, as the length of the string doesn't change. So I agree with @jrfnl on this.

@dmsnell
Copy link
Contributor

dmsnell commented Oct 4, 2022

this is fine, and I'm comfortable merging, but we should note that this doesn't have a clear performance impact.

it is completely redundant and inefficient to recalculate the length for every loop.

this is inaccurate, as it's not completely inefficient and the length is not recomputed - it's returned as a property lookup on the ZSTR value inside PHP.


thanks for the patch!

@anton-vlasenko
Copy link
Contributor

@dmsnell If you are comfortable merging, would you please approve this PR?
Unfortunately, I cannot merge it because GH says there are requested changes that have to be addressed.
Many thanks!

@anton-vlasenko anton-vlasenko added [Type] Code Quality Issues or PRs that relate to code quality [Type] Performance Related to performance efforts labels Oct 6, 2022
@anton-vlasenko anton-vlasenko merged commit 9004df2 into trunk Oct 6, 2022
@anton-vlasenko anton-vlasenko deleted the QA/no-function-calls-in-loop-conditions branch October 6, 2022 19:52
@anton-vlasenko anton-vlasenko removed the [Type] Code Quality Issues or PRs that relate to code quality label Oct 6, 2022
@github-actions github-actions bot added this to the Gutenberg 14.4 milestone Oct 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Performance Related to performance efforts
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants