-
Notifications
You must be signed in to change notification settings - Fork 24
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
Runtime overhead seen with boost units #281
Comments
Some of the simpler benchmark tests that show the difference:
Maybe an even more direct demonstration of the problem is this code. |
With the previously mentioned merge (of PR #282), and the library built with boost units enabled, I see benchmark results like:
The particularly interesting part of these results is:
All here looks well up till What's most bizarre for me is what happens timing wise with the |
Expected/Desired Behavior or Experience:
Using boost units adds no runtime overhead. I.e. benchmark times don't increase when boost units are enabled.
Actual Behavior:
Enabling the use of boost units (for strongly typed physical units) causes tests like the
World.TilesComesToRest
test to increase in runtime by some 10% or so.A more detailed write-up is available from the Run-time overhead with boost.units question on StackOverflow.
An online conversation about this issue can be found in the Add constexpr support conversation. Some interesting responses were posted on Jul 2, 2017 and Jul 15, 2017.
Steps to Reproduce the Actual Behavior:
Build the library and its UnitTests and Benchmark dependents both with and with boost units support. For instructions for building with boost units support enabled, see the PhysicalUnits.md document.
The text was updated successfully, but these errors were encountered: