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

fix(clang-tidy): Apply performance fixes from clang-tidy #3046

Merged
merged 6 commits into from Jun 19, 2021

Conversation

Skylion007
Copy link
Collaborator

Description

  • Spoke with @rwgk about applying performance fixes from clang-tidy which he was supportive of. While there are some blockers preventing this from being enabled automatically, (mainly the lack of a hierarchical config to prevent the test files from being edited), I went ahead and applied various fixes from the performance checks. I also formatted all diffs with clang-format-diff.py .
  • Most of changes can be summarized as (unnecessary std::move)
  • Copies that should be std::move instead
  • Copying in values that should be const references.
  • Forgetting to add noexcept to move constructors.
  • Let me know if any of the changes should be spun off or such because they are ABI breaking or can be applied immediately.

Suggested changelog entry:

* Various performance micro-optimizations applied to the codebase using clang-tidy.

@rwgk
Copy link
Collaborator

rwgk commented Jun 17, 2021

This is awesome!

How much trouble is it for you to apply the exact same process to the smart_holder branch?

Background:

  • The smart_holder branch is what we use Google-internally.
  • I'm working to keep it in sync with master as much as possible, but there are some non-trivial diffs.

Hope:

  • If you apply the exact same process to the smart_holder branch we won't have merge conflicts.

But:

  • I'm not sure that's actually better or easier than dealing with the merge conflicts.
  • In any event, I'd really want the same cleanup for the code that's only on the smart_holder branch.

Also:

  • I can run the Google-internal global testing (includes exercising a ton of open source code) only against the smart_holder branch.

Which means if we do master-merge followed by smart_holder-merge-from-master followed by testing, that testing may uncover some things we need to fix on master, so we have to go back and forth through the branches. If it's reasonably automatic to apply your process to both master and smart_holder straightaway, we'd have a more holistic picture.

@Skylion007
Copy link
Collaborator Author

This is awesome!

How much trouble is it for you to apply the exact same process to the smart_holder branch?

Background:

* The smart_holder branch is what we use Google-internally.

* I'm working to keep it in sync with master as much as possible, but there are some non-trivial diffs.

Hope:

* If you apply the exact same process to the smart_holder branch we won't have merge conflicts.

But:

* I'm not sure that's actually better or easier than dealing with the merge conflicts.

* In any event, I'd really want the same cleanup for the code that's only on the smart_holder branch.

Also:

* I can run the Google-internal global testing (includes exercising a ton of open source code) only against the smart_holder branch.

Which means if we do master-merge followed by smart_holder-merge-from-master followed by testing, that testing may uncover some things we need to fix on master, so we have to go back and forth through the branches. If it's reasonably automatic to apply your process to both master and smart_holder straightaway, we'd have a more holistic picture.

Not that much trouble, I'll go ahead and submit a PR there as well.

@rwgk
Copy link
Collaborator

rwgk commented Jun 17, 2021 via email

@Skylion007
Copy link
Collaborator Author

Yeah, I am making a new branch with the latest fixes.

@Skylion007
Copy link
Collaborator Author

@rwgk
Copy link
Collaborator

rwgk commented Jun 18, 2021 via email

@Skylion007
Copy link
Collaborator Author

Opened a PR assuming you want to make it in the main smart-holder branch. If you want to pull it somewhere else here is the dialogue for doing so: https://github.com/pybind/pybind11/compare/master...Skylion007:clang-tidy-sh-perf-latest?expand=1

@rwgk
Copy link
Collaborator

rwgk commented Jun 18, 2021 via email

@henryiii henryiii changed the title [Clang-Tidy] Apply performance fixes from clang-tidy fix(clang-tidy): Apply performance fixes from clang-tidy Jun 18, 2021
Copy link
Collaborator

@rwgk rwgk left a comment

Choose a reason for hiding this comment

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

Via #3048 I ran these changes with ASAN, MSAN, and the Google-internal global testing. I'd love to see this merged.

Copy link
Member

@wjakob wjakob left a comment

Choose a reason for hiding this comment

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

That's actually pretty neat. They all look fine to me, except for one minor change I would have made.

@@ -164,10 +164,10 @@ struct npy_api {
NPY_ULONG_, NPY_ULONGLONG_, NPY_UINT_),
};

typedef struct {
using PyArray_Dims = struct {
Copy link
Member

Choose a reason for hiding this comment

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

Why not just struct PyArray_Dims?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Was here when I got here. Changed.

return expr; \
}, \
name(op), is_method(m_base), arg("other"))
#define PYBIND11_ENUM_OP_STRICT(op, expr, strict_behavior) \
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

clang-format required this change.

@@ -164,7 +164,7 @@ struct npy_api {
NPY_ULONG_, NPY_ULONGLONG_, NPY_UINT_),
};

using PyArray_Dims = struct {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm just curious, when I saw this initially I thought it was something automatically applied, thinking "probably for a good reason". Was that not the case?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It should have been automatically caught by the github actions tbh, but it wasn't. From modernize-use-using check

@rwgk rwgk merged commit af6218f into pybind:master Jun 19, 2021
@github-actions github-actions bot added the needs changelog Possibly needs a changelog entry label Jun 19, 2021
@rwgk
Copy link
Collaborator

rwgk commented Jun 19, 2021

Thanks Aaron!

@Skylion007 Skylion007 deleted the clang-tidy-performance-fixes branch June 21, 2021 17:45
@henryiii henryiii removed the needs changelog Possibly needs a changelog entry label Jul 13, 2021
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.

None yet

4 participants