-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Minor cleanup and optimization of Sketch #24964
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
Conversation
src/path_converters.h
Outdated
len = sqrt(len); | ||
*x += r * num / len; | ||
*y += r * -den / len; | ||
double r = sin(m_p * (2.0 * d_M_PI) / m_length) * m_scale; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two minor changes since the review:
- Brackets to enable constant folding here.
- Change
+= x * -y
to-= x * y
below.
At least both these give simplifications in the LLVM IR (maybe the backend will still provide the same code in the end though, but probably not for the first one due to FP aspects).
I did a major rewrite after reading up on Added some comments about how it is refactored. For my test example, similar to #24908 (comment), the time doing pow was 33% of the total time, now the time doing exp is 16% of the total time. (Hard to compare actual times as the workloads were slightly different on the machine...) |
One may want to move the random number generation and exp into the if-clause. However, that may change the outcome, although I guess that the if-clause is primarily for avoiding division by zero in rare cases rather than something that is heavily used, so there may be limited performance benefits and limited changes in the outcome. Edit: I guess what I am trying to say is that if there is a performance benefit of moving it there, it will also modify the output to a larger extent as what we are doing is skipping updating the phase and random sequence when len is 0. So probably not a good idea. |
Is this code path tested? Do you have evidence that this is actually a speed up? |
We will hit this in : https://github.com/matplotlib/matplotlib/blob/main/lib/matplotlib/tests/baseline_images/test_path/xkcd.png I'm happy to take Oscar at his word that this is faster. |
Yes. it is faster (and tested). At least on x86, but shouldn't be slower on other architectures (as in about as fast, worst case). The background is that (Been focusing quite heavily on a work project recently...) |
PR Summary
Getting rid of a few redundant/not required computations. Have not checked the assembly code to confirm that the compiler doesn't already optimize it away though.
PR Checklist
Documentation and Tests
pytest
passes)Release Notes
.. versionadded::
directive in the docstring and documented indoc/users/next_whats_new/
.. versionchanged::
directive in the docstring and documented indoc/api/next_api_changes/
next_whats_new/README.rst
ornext_api_changes/README.rst