-
-
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
Code loading: track chosen cachefile and load the module path #37421
Conversation
@@ -813,13 +813,18 @@ function require(into::Module, mod::Symbol) | |||
return require(uuidkey, cache) | |||
end | |||
|
|||
const pkgcachefiles = Dict{PkgId,String}() | |||
struct PkgOrigin |
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.
<3
An alternative to With Revise3's aggregate latency (time to load package + extra overhead for loading the next package while compiling Revise's internals) approaching 0.75s, my overall sense is that now is not the time to contemplate this, but that perhaps around the 1.7 time frame (once Revise3 has had a chance to stabilize) it might be time to consider this option more seriously. But of course, by that point maybe we'll have better precompilation, in which case the benefits diminish unless we think that a lot of the information might be useful anyway. Thoughts? |
Maybe a bit overkill to move the Revise stuff into Base. As you say, perhaps reevaluate for 1.7? |
These changes allow Revise to leverage precompiled Base machinery, dropping about 150ms from Revise's extra latency penalty for the first package load.
7887cd9
to
7f93147
Compare
Ah, nice. IIUC, this will allow us to trivially fix |
Yeah, someone will have to figure out the right place to set those values, but presuming that's fairly straightforward this should indeed make it pretty easy. |
See #37586 |
These changes allow Revise to leverage precompiled Base machinery, dropping about 150ms from Revise's extra latency penalty for the first package load. Especially for the upcoming Revise3, that's a pretty large fraction of its total latency (ballpark 750ms for both loading Revise and the penalty for the subsequent package load).
Revise had an
mtime
hack to try to guess which precompile file was being used, so this should make things more robust too since it keeps track of which one actually got loaded.