Skip to content

Remove rarely true check in char_traits::move#2083

Merged
StephanTLavavej merged 1 commit intomicrosoft:mainfrom
LumioseSil:patch-5
Aug 6, 2021
Merged

Remove rarely true check in char_traits::move#2083
StephanTLavavej merged 1 commit intomicrosoft:mainfrom
LumioseSil:patch-5

Conversation

@LumioseSil
Copy link
Copy Markdown
Contributor

While it is faster to just leave when the source and destination are the same, most programmers would not make that mistake, and if they did, it would be a rarity and a reflection of something going wrong in their code in the first place.

There is no reason to do this check if speed and code size are of utmost importance.

@LumioseSil LumioseSil requested a review from a team as a code owner July 29, 2021 16:46
@LumioseSil LumioseSil changed the title Remove rarely true check Remove rarely true check in xstring move Jul 29, 2021
@LumioseSil LumioseSil changed the title Remove rarely true check in xstring move Remove rarely true check in char_traits::move Jul 29, 2021
@AdamBucior
Copy link
Copy Markdown
Contributor

There is no reason to do this check if speed and code size are of utmost importance.

This code is only executed at compile time, but I agree that it's unnecessary.

@CaseyCarter CaseyCarter added the enhancement Something can be improved label Jul 29, 2021
@StephanTLavavej StephanTLavavej self-assigned this Aug 5, 2021
@LumioseSil
Copy link
Copy Markdown
Contributor Author

On second thought, since this is a compile time constant, I wonder if this is a good idea.

@CaseyCarter
Copy link
Copy Markdown
Contributor

On second thought, since this is a compile time constant, I wonder if this is a good idea.

My intuition is that "self-assignment" at compile time is as rare as "self-assignment" at runtime and that the guard won't trigger often enough to offset the cost of evaluation. I don't think any of our supported compilers currently implements a branch predictor for constexpr evaluation, so I suspect this is compile-time guard has a larger negative impact than would a similar runtime guard. I would nonetheless be surprised to see a benchmark which demonstrated a statistically significant difference between having and not having the guard, but I'm happy to have fewer lines of code to maintain.

@LumioseSil
Copy link
Copy Markdown
Contributor Author

True. Maybe when our compiler is better.

While it is faster to just leave when the source and destination are the same, most programmers would not make that mistake, and if they did, it would be a rarity and a reflection of something going wrong in their code in the first place.

There is no reason to do this check if speed and code size are of utmost importance.
@LumioseSil
Copy link
Copy Markdown
Contributor Author

Alright I squashed everything and rebased, so this should be good to go!

@CaseyCarter
Copy link
Copy Markdown
Contributor

Alright I squashed everything and rebased, so this should be good to go!

It's not an issue given how small this change is, but for future reference please avoid force-pushing the branch since it interferes with incremental code review. (Merging main into your branch is a good alternative to rebasing if you need to pull new stuff into your branch, and we'll "Squash and merge" anyway when we merge.)

@LumioseSil
Copy link
Copy Markdown
Contributor Author

Alright, thank you!

@StephanTLavavej StephanTLavavej merged commit d3840f4 into microsoft:main Aug 6, 2021
@StephanTLavavej
Copy link
Copy Markdown
Member

Thanks for removing this unnecessary code! 😺 🧹 🎉

@LumioseSil LumioseSil deleted the patch-5 branch September 26, 2022 16:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Something can be improved

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants