i have a hazy sense that both the "MemberImportVisibility" (SE-0444) and "InternalImportsByDefault" (SE-0409) features should in theory save the compiler some work, since they both restrict a 'search space' of sorts. before i attempt to validate this assumption myself, i was wondering if anyone more familiar with their impact on the compiler's implementation might be able to shed light on the question. apologies for the direct pings, but @tshortli and @xymus, as the feature authors, do you have a sense of whether my assumption is accurate (or if anyone else happens to know, do feel free to chime in)? if so, under what circumstances would you expect the compiler to most benefit from enabling these features? thanks in advance!
2 Likes
having now read through this post: [Pitch] Allow non-resilient modules to hide dependencies to clients and the SE-409 document more[1], i'm a bit less certain the benefits i'd imagined might actually be realized with things as they stand, at least in the context most relevant to me (many-module targets built non-resiliently). IIUC, even with internal imports by default enabled, the compiler still has to (potentially?) load transitive internal dependencies so that type layouts can be computed.
still, i wonder if there aren't some things that might expect to see improved performance with either of these features enabled.
Neither feature is designed to improve build performance for the module adopting the feature.
MemberImportVisibility changes rules regarding which candidates are valid when resolving member declarations, but those unviable members are still found during overload resolution and considered as fallbacks in order to provide a good diagnostic experience when you’ve forgotten an import.
InternalImportsByDefault can indirectly improve performance for clients of the adopting module if the adopter enables library evolution, but that benefit comes from hiding dependencies that were unnecessarily exposed and were causing extra modules to be compiled as compilation inputs. This benefit isn’t really a direct result of the feature though since minimizing exposed dependencies can also be accomplished for library evolution modules without enabling the feature, though.
2 Likes
thanks for the confirmation Allan – much appreciated!
1 Like