astro-informatics / sopt

Sparse OPTimisation using state-of-the-art convex optimisation algorithms.
http://astro-informatics.github.io/sopt/
GNU General Public License v2.0
9 stars 11 forks source link

Replace postfix increment and decrement operators with their prefix equivalents #385

Open krishnakumarg1984 opened 1 year ago

krishnakumarg1984 commented 1 year ago

There is no reason whatsoever to use the postfix versions of the increment and decrement operator.

In postfix incrementing, first, a copy of the operand is made. Then the operand (not the copy) is incremented. Finally, the copy (not the original) is evaluated. Then the temporary copy is discarded. The postfix version takes a lot more steps, and thus may not be as performant as the prefix version.

In practice, any non-toy compiler will optimise away these steps and the postfix version is likely to have the same performance as the prefix versions for fundamental data types and even for compound types.

However, for user-defined data types where these operators may be overloaded, the postfix version is likely to be slower.

References

There should be no reason whatsoever to use these postfix operators, and we should strive to break this old habit asap.

SJaffa commented 1 year ago

I've always seen loops taught using the postfix operator so this might be a case where it is best to stick with the convention so as not to confuse less experienced programmers. Is this likely to give a significant performance increase? If not I'd favour readability for the researchers.

krishnakumarg1984 commented 1 year ago

@SJaffa

This blog-post is an eye-opening read on pre-increment vs post-increment for loops.

Guideline: Prefer preincrement. Only use postincrement if you’re going to use the original value.


If not I'd favour readability for the researchers.

Did you mean familiarity? They are both equally readable, no?

I've always seen loops taught using the postfix operator

This abhorrent practice needs to stop sooner than later :) Have a look at this answer or this one.

Is this likely to give a significant performance increase?

Yes. For user-defined types (not in this PR though).

The post-incrementation i++ needs to create a temporary variable to store the original value of i, then performs the incrementation and returns the temporary variable. The pre-incrementation ++i doesn't create a temporary variable.


In postfix incrementing, first, a copy of the operand is made. Then the operand (not the copy) is incremented. Finally, the copy (not the original) is evaluated. Then the temporary copy is discarded. The postfix version takes a lot more steps, and thus may not be as performant as the prefix version.

SJaffa commented 1 year ago

If not I'd favour readability for the researchers.

Did you mean familiarity? They are both equally readable, no?

I mean readability of the code as a whole. While i++ and ++i are equally quick to read, having even small bits of unfamiliar syntax makes the code significantly harder to read and digest. I learned this from the Programmer's Brain which we are reading in ARC book club, I can lend it to you if you like, really good read!