-
Notifications
You must be signed in to change notification settings - Fork 452
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
compile-time optimization #219
Comments
Thank you for your analysis, now I am at least splitting the header into several smaller ones, then I will look at how to optimize functions |
Seems like all these calls quickly add up: magic_enum/include/magic_enum.hpp Line 556 in 596f00c
The variant used for customization also has some overhead. And that pretty_name function is also a good optimization target since it's called so often. Not sure why it's doing a complicated identifier search, in my toy code I just searched for the = /< . I guess is_valid can't be optimized much since enum identifiers can end in a number, but if n returned a string_view the copy to static_string could be avoided in that case.
|
Good catch |
Though it's probably faster to just hard-code the offsets: https://godbolt.org/z/exqMMq5G3 |
It seems to me that the optimization |
It is cause it gets called max-min times via is_valid for each enum after all. Even after my optimization |
I'll try to replace the variant with something like tuple, I need to think about it. |
The profile was a bit skewed though due to other includes in the #include <magic_enum.hpp>
int main(){} Parsing took 400ms in this run, (166ms of which is for which would often already be included like in the test code): Still, |
Yes, I thought it would be better to take std::pair |
I don't have new idea what can be optimized yet. |
Parsing times are better after #221 but as soon as you actually use magic_enum template instantiations are still the main issue. |
The code is quite heavy on compile-time and could use some optimizations (e.g. every
enum_cast
takes 1s to instantiate in my test).clang
got improved recently to coverconstexpr
evaluations in time traces which will come in handy: https://reviews.llvm.org/D136022.Half of the parsing time alone is spent on
constexpr_switch
for example, andis_flags_enum
is very heavy to instantiate because it callsvalues
.Here's the test-cpp17 time trace generated with
-ftime-trace -ftime-trace-granularity=100
, can be viewed with https://ui.perfetto.dev.The text was updated successfully, but these errors were encountered: