precompile+ #15934
Merged
precompile+ #15934
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @@ -93,26 +103,24 @@ function find_in_path(name::AbstractString, wd = pwd()) | |||
| if wd !== nothing | |||
| isfile_casesensitive(joinpath(wd,name)) && return joinpath(wd,name) | |||
| end | |||
| for prefix in [Pkg.dir(); LOAD_PATH] | |||
There was a problem hiding this comment.
@JeffBezanson compiling this vcat seems to be a difficult problem for inference to pre-generate, so i've rewritten in a way that generates less code (and thus saves a bit of time, multiplied by every precompiled module startup)
vtjnash
force-pushed
the
jn/precompile_plus
branch
from
ff61785 to
ad37021
Compare
|
Gulp. Increases sys.so by 20%. |
|
yes. but, just think of the savings of not creating that same |
|
With this change, test-numbers takes ~130 seconds. Disabling the extra precompile brings it back to ~90 seconds. I tried filtering out types containing DataType in jl_get_specialization1 but no luck so far. |
Closed
| # `wd` is a working directory to search. defaults to current working directory. | ||
| # if `wd === nothing`, no extra path is searched. | ||
| function find_in_path(name::AbstractString, wd = pwd()) | ||
| function find_in_path(name::ByteString, wd = pwd()) |
There was a problem hiding this comment.
this caused JuliaLang/PkgDev.jl#38 (comment) and needs a converting fallback
timholy
added a commit
that referenced
this pull request
Apr 23, 2016
timholy
added a commit
that referenced
this pull request
Apr 23, 2016
timholy
added a commit
that referenced
this pull request
Apr 23, 2016
vtjnash
added a commit
that referenced
this pull request
Apr 27, 2016
previously, a cache entry would be widened beyond the despecialization heuristic, creating an ordering dependence such that after inserting a Function into the cache (as Any) or a Tuple (as DataType), no more methods would attempt to specialize that slot should fix the issue noted #15934 (comment)
vtjnash
added a commit
that referenced
this pull request
Apr 28, 2016
previously, a cache entry would be widened beyond the despecialization heuristic, creating an ordering dependence such that after inserting a Function into the cache (as Any) or a Tuple (as DataType), no more methods would attempt to specialize that slot should fix the issue noted #15934 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this make the precompile.jl file more effective. previously,
jl_get_specialization1would get called on the toplevel function and any direct leaf call, recursively. this extends that to make sure it gets called on anything inference thought might get called.the primary relevant improvement for
loading.jlwas that a ByteString return type didn't transfer a high compile-time penalty into runtime.