Skip to content
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

Reduce latency of Revise.revise() #38906

Merged
merged 2 commits into from
Dec 17, 2020
Merged

Reduce latency of Revise.revise() #38906

merged 2 commits into from
Dec 17, 2020

Conversation

timholy
Copy link
Member

@timholy timholy commented Dec 16, 2020

Perhaps the most annoying thing about Revise now is that the first revision is quite slow, about 3.1s on my machine.
This drops the time to 1.85s, a nice improvement.

This was curious, so by way of explanation I'm just going to paste the comments of both commits.

Commit 1:
Add precompiles to reduce time to first Revise.revise()

Perhaps the most annoying thing about Revise now is that the first
revision is quite slow, about 3.1s on my machine. This PR drops the time
to about 2.4s. Basically the idea is to precompile statements that
Revise will need.

Discovered via the new snoopi_deep/Core.Compiler.Timings framework.


Commit 2:
Internalize Revise precompiles into Base

For some reason (perhaps #32705?) most or all of these fail if they
are emitted as precompile statements, so this moves them into Base itself.

This drops the time for a revision down to 1.85s.


The commits are separate because it was an interesting discovery on its own, and the second is evidently ugly so it would be nice not to need it.

Perhaps the most annoying thing about Revise now is that the first
revision is quite slow, about 3.1s on my machine. This PR drops the time
to about 2.4s. Basically the idea is to precompile statements that
Revise will need.

Discovered via the new snoopi_deep/Core.Compiler.Timings framework.
For some reason (perhaps #32705?) most or all of these fail if they
are emitted as precompile statements, so this moves them into Base itself.

This drops the time for a revision down to 1.85s.
@timholy timholy added compiler:latency Compiler latency backport 1.6 Change should be backported to release-1.6 labels Dec 16, 2020
@Sacha0
Copy link
Member

Sacha0 commented Dec 16, 2020

(The second commit might interest @NHDaly 👀.)

@KristofferC KristofferC mentioned this pull request Dec 17, 2020
53 tasks
@KristofferC KristofferC merged commit b5dd8a1 into master Dec 17, 2020
@KristofferC KristofferC deleted the teh/precompiles_revise branch December 17, 2020 11:33
@KristofferC KristofferC removed the backport 1.6 Change should be backported to release-1.6 label Dec 19, 2020
timholy added a commit to timholy/Revise.jl that referenced this pull request Dec 20, 2020
Investigation via `SnoopCompile.@snoopi_deep` identified several
opportunities to reduce latency:
- JuliaLang/julia#38906
- JuliaDebug/JuliaInterpreter.jl#461
- JuliaDebug/LoweredCodeUtils.jl#58

Together with the changes here, the aggregate effect is to reduce
the time for the first revision from 3.1s
to about 1.5s. That's much more reasonable.
timholy added a commit to timholy/Revise.jl that referenced this pull request Dec 21, 2020
Investigation via `SnoopCompile.@snoopi_deep` identified several
opportunities to reduce latency:
- JuliaLang/julia#38906
- JuliaDebug/JuliaInterpreter.jl#461
- JuliaDebug/LoweredCodeUtils.jl#58

Together with the changes here, the aggregate effect is to reduce
the time for the first revision from 3.1s
to about 1.5s. That's much more reasonable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:latency Compiler latency
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants