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

Make fewer copies of arrays #2114

Merged
merged 3 commits into from
Nov 19, 2024
Merged

Conversation

eltoder
Copy link
Contributor

@eltoder eltoder commented Nov 14, 2024

No description provided.

@coveralls
Copy link

coveralls commented Nov 14, 2024

Coverage Status

coverage: 73.049% (-0.003%) from 73.052%
when pulling 0fb7e68 on eltoder:feature/array-copies
into a07bf7b on lballabio:master.

@@ -304,7 +298,8 @@ template <class Curve> void GlobalBootstrap<Curve>::calculate() const {
Curve *ts_;
const std::vector<Real> lowerBounds_, upperBounds_;
Copy link
Owner

Choose a reason for hiding this comment

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

This class is local to the function, instantiated and then destroyed at function end. You can declare lowerBounds_ and upperBounds_ as const & instead and avoid all the moves.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, but note that constructor arguments for TargetFunction then should not be declared as const&, because doing so would allow passing temporary objects. We are then storing a reference to a temporary object, which will be destroyed at the end of the statement. I declared them as const pointers instead.

Copy link
Owner

Choose a reason for hiding this comment

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

It might be an unnecessary precaution. This function is the only user of TargetFunction, nobody is going to pass temporary objects. But it's ok either way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's safe at the moment, but we might refractor the code in the future to, say, use std ranges. I'd rather have a compile time error than debug random numbers coming out from bootstrapping.

Copy link
Contributor

Choose a reason for hiding this comment

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

My two cents is that const reference is better syntactically and stylistically, and that any regression from future refactoring will be caught right away by the address sanitizer CI job as long as there are adequate unit tests in place.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, Google C++ style prohibits non-const references and requires using pointers to mutate arguments, so using pointers for retained arguments is very natural.

Copy link
Owner

Choose a reason for hiding this comment

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

Too bad the interface of Problem requires this to inherit from CostFunction. Otherwise, the whole thing could be a lambda and just capture what it needs. Oh well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point. We can make a templated implementation of CostFunction that wraps a functor. Then we can write this as a lambda.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How's this #2117?

Copy link
Owner

Choose a reason for hiding this comment

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

Great, thanks.

Comment on lines -58 to -67
void fcn(int m,
int n,
Real* x,
Real* fvec,
int* iflag);
void jacFcn(int m,
int n,
Real* x,
Real* fjac,
int* iflag);
Copy link
Owner

Choose a reason for hiding this comment

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

They shouldn't have been in the public interface but they are. I would deprecate them (and forward their calls to the private ones, of course).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@lballabio lballabio added this to the Release 1.37 milestone Nov 19, 2024
@lballabio lballabio merged commit a83be9e into lballabio:master Nov 19, 2024
42 checks passed
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.

4 participants