-
Notifications
You must be signed in to change notification settings - Fork 323
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
Replace all from ... export all
with explicit exports
#10369
Conversation
And ImportResolverAlgorithm can import it
…inistic. We don't care about it.
module method can be exported directly. And static method can be exported by name.
engine/runtime-compiler/src/main/java/org/enso/compiler/phase/ImportResolverAlgorithm.java
Outdated
Show resolved
Hide resolved
from project.Meta.Enso_Project export enso_project | ||
from project.Network.Extensions export all | ||
from project.System.File_Format export Auto_Detect, Bytes, File_Format, Infer, JSON_Format, Plain_Text_Format | ||
export project.Data.Boolean.Boolean |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is from ... export
deprecated even when it's not using all
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are not deprecated, they are just now suffering from #10399. Until that issue is fixed, rule of a thumb is to just use plain export ...
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving the libs bits.
Failing tests:
Close, so close... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's great to see all tests are green! I am looking forward to see the speedup after integration.
There is not enough time to run proper benchmarks before integration. But I have at least run some benchmarks locally (lower score is better - ms/op):
Moreover, local experiments with running
revealed that compilation of Standard.Base now takes 6 seconds, versus the old 31 seconds. |
Done a brief QA with the IDE and everything seems fine. Integrating ... |
export in `A_Module.enso`: | ||
|
||
``` | ||
export project.A_Module.export |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This probably should have been:
- export project.A_Module.export
+ export project.A_Module.method
if (parts.size() < 3) { | ||
return null; | ||
} | ||
var constructors = definedConstructors(imp); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to return a Map
here? Then the O(N) stream filter could potentially become an O(log N) / O(1) map access.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also looking at the code it seems like we are constructing this on each call. Have you considered caching the result? I'm not sure how many times this is called, but I'd assume it can be called a lot on heavily used modules, so avoiding to re-construct this List (or Map) every time could give us some additional speedup.
* Ensures that all the symbols that are exported exist. If not, an IR error is generated. It is not | ||
* a {@link IRPass compiler pass} because it needs access to {@link | ||
* org.enso.compiler.PackageRepository}. Ignores renamed exports. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand the explanation why this isn't a compiler pass.
I mean I'm not convinced it has to be.
But we can access PackageRepository
in passes, I've been doing this for #9812.
var packageRepo = moduleContext.pkgRepo().isDefined() ? moduleContext.pkgRepo().get() : null;
or is something wrong about this pattern?
Vast majority of CPU time in ExportsResolution is spent in [BindingsMap.SymbolRestriction.optimize](https://github.com/enso-org/enso/blob/9a373572470ed434fb7b99114553c411ad54718e/engine/runtime-compiler/src/main/scala/org/enso/compiler/phase/ExportsResolution.scala#L173). #10369 dealt with this. This PR only adds the `ExportImportResolutionBenchmark`. # Important Notes - Introduce new [ExportImportResolutionBenchmark](https://github.com/enso-org/enso/blob/9e70f675d8c6d60b74733606b1c48f52e55da7ba/engine/runtime-benchmarks/src/main/java/org/enso/compiler/benchmarks/exportimport/ExportImportResolutionBenchmark.java) that measures the performance of import and export resolution only. - Note that the already existing [ImportStandardLibrariesBenchmark](https://github.com/enso-org/enso/blob/4d49b003752e8771e95d5ae379ce953c85ef020c/engine/runtime-benchmarks/src/main/java/org/enso/compiler/benchmarks/module/ImportStandardLibrariesBenchmark.java) is probably fine for the purpose, but I just wanted to be sure that **ONLY** the import/export resolution is measured and nothing else, so I have isolated that into a new benchmark.
Follow-up of #10274. Partially fixes #10258, #6729, #9236
Pull Request Description
Replaces all
from ... export all
with explicit by-name exports.Important Notes
isAll
andhiding
fields from Export IRBindingsMap
.Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
TypeScript,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.