-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Member name lookup] Eliminate non-lazy member loading. #66266
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
[Member name lookup] Eliminate non-lazy member loading. #66266
Conversation
@swift-ci please smoke test |
@swift-ci please test compiler performance |
Lazy member loading has been in use and the default for several years now. However, the lazy loading was disabled for any type whose primary definition was parsed even though some of its extensions could have been deserialized, e.g., from a Clang module. Moreover, the non-lazy path walked all of the extensions of such a type for all member name lookup operations. Faced with a large number of extensions to the same type (in my example, 6,000), this walk of the list of the extensions could dominate type-checking time. Eliminate all effects of the `-disable-named-lazy-member-loading` flag, and always use the "lazy" path, which effectively does no work for parsed type definitions and extensions thereof. The example with 6,000 extensions of a single type goes from type checking in 6 seconds down to type checking in 0.6 seconds, and name lookup completely disappears from the profiling trace. The deleted tests relied on the flag that is now inert. They aren't by themselves providing much value nowadays, and it's better to have the simpler (and more efficient) implementation of member name lookup be the only one.
A recent refactoring uncovered two places where we could end up importing a C++ field declaration as a property more than once: 1. Importing the declaration context of a field in C++ mode can then go import all of the fields. In such a case, check that the field we're importing didn't happen already, and bail out early if it did. This is common practice in the Clang importer but wasn't happening here. 2. One caller to the function that imported a field from a C++ base class into its inheriting class (as a computed property) wasn't checking the cache, and therefore created a redundant version. Fix both issues.
8d8b360
to
43d360c
Compare
@swift-ci please smoke test |
@swift-ci please test compiler performance |
1 similar comment
@swift-ci please test compiler performance |
@swift-ci please smoke test compiler performance |
@swift-ci please test compiler performance |
@swift-ci please smoke test |
1 similar comment
@swift-ci please smoke test |
@swift-ci please test compiler performance |
1b4c989
to
8794c02
Compare
@swift-ci please test compiler performance |
@swift-ci please smoke test |
@swift-ci please test compiler performance |
@swift-ci please test source compatibility |
@swift-ci please smoke test compiler performance |
1 similar comment
@swift-ci please smoke test compiler performance |
Lazy member loading has been in use and the default for several years
now. However, the lazy loading was disabled for any type whose primary
definition was parsed even though some of its extensions could have
been deserialized, e.g., from a Clang module. Moreover, the non-lazy
path walked all of the extensions of such a type for all member name
lookup operations. Faced with a large number of extensions to the same
type (in my example, 6,000), this walk of the list of the extensions
could dominate type-checking time.
Eliminate all effects of the
-disable-named-lazy-member-loading
flag, and always use the "lazy" path, which effectively does no work
for parsed type definitions and extensions thereof. The example with
6,000 extensions of a single type goes from type checking in 6 seconds
down to type checking in 0.6 seconds, and name lookup completely
disappears from the profiling trace.
The deleted tests relied on the flag that is now inert. They aren't by
themselves providing much value nowadays, and it's better to have the
simpler (and more efficient) implementation of member name lookup be
the only one.