Fix constexpr of gregorian::date::date(special_values) to improve perf #214
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GCC up to at least 10.2 fail to resolve gregorian::date::date(special_values) as constexpr function due to assignment to *this within the constructor. Refactoring constructor to initialize the instance once leads to large performance improvement.
Codecov Report
@@ Coverage Diff @@
## develop #214 +/- ##
========================================
Coverage 91.74% 91.75%
========================================
Files 77 77
Lines 4823 4827 +4
========================================
+ Hits 4425 4429 +4
Misses 398 398
Continue to review full report at Codecov.
|
|
Looks good - thanks! |
JeffGarland
added a commit
that referenced
this pull request
Oct 31, 2022
* fix typo in time_period docs (#212) Co-authored-by: Quinn O'Connor <qoconnor@fastenal.com> * Fix constexpr of gregorian::date::date(special_values) to improve perf (#214) GCC up to at least 10.2 fail to resolve gregorian::date::date(special_values) as constexpr function due to assignment to *this within the constructor. Refactoring constructor to initialize the instance once leads to large performance improvement. * Avoid using likely function as multiple projects define a likely macro (#216) * Iso doc fixes (#215) * to_iso_*string() use "." as fractional separator The fractional separator for the various to_iso_* methods is "." not "," (per to_iso_string_type() implementation). Fix the documentation to match the implementation. * use "ISO 8601" not "iso" in documentation The standard is "ISO 8601", so use that instead of just "iso" or "ISO" in comments and documentation. * fractional seconds only included if non-zero (#110) Consistently document that the fractional seconds are only included if non-zero. Use "where fffffffff" not "were fff". * Fix ccache saving on cache hit (#211) See boostorg/boost-ci#166 * chore: bump macos runner version (#213) GitHub Action is sunsetting the macOS 10.15 Actions runner. It will stop working intermittently until being completely removed by 2022-8-30: https://github.blog/changelog/2022-07-20-github-actions-the-macos-10-15-actions-runner-image-is-being-deprecated-and-will-be-removed-by-8-30-22 Co-authored-by: Quinnsicle <qtoconnor@gmail.com> Co-authored-by: Quinn O'Connor <qoconnor@fastenal.com> Co-authored-by: Povilas Kanapickas <povilas@radix.lt> Co-authored-by: Antony Polukhin <antoshkka@gmail.com> Co-authored-by: Luke Mewburn <luke@mewburn.net> Co-authored-by: Alexander Grund <Flamefire@users.noreply.github.com> Co-authored-by: Baoshuo Ren <i@baoshuo.ren>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #121
Turns out even when all functions without the library are prefixed with constexpr, GCC up to at least v10 does not consider this constructor as constexpr at least when generating code.
The culprit is the assignment to
*this. Refactoring the code to initialize the instance just once improves code generation significantly. Note that clang since at least v11 does not exhibit this problem.