-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
compiler performance regression with long tuples #28890
Comments
StaticArrays is one case where this shows up, and #27488 (comment) shows that it comes up in AD implementations as well. I think I talked with @Keno before about this case and he mentioned that in theory the compiler could have a better representation for it? |
I would classify this as a compiler performance regression, and without more investigation we don't know whether |
NTuple
types as homogeneous
This has steadily gotten slightly better:
More helpfully though:
So we're back to v0.6- timings. |
There seem to be some performance regressions in compile time of
NTuple
in 1.0. Note, for example,1.0:
0.6.4:
We were speculating that this is due to #27398. While it doesn't seem unreasonable that the compiler really has to think about 256 type long signatures, we believe that the compiler may not know that all the types are guaranteed to be the same since (as far as I know)
NTuple
is nothing more than an alias.Am I getting the story here correct? Would it be possible to make the compiler know that
NTuple
is promised to be homogeneous, but otherwise retain the current behavior?I apologize if this is somehow duplicating or echoing existing issues, I wasn't able to find anything that addressed this directly.
(Thanks to @ChrisRackauckas for useful discussion on this.)
The text was updated successfully, but these errors were encountered: