decrease method count for eltype for Tuple, decrease max_methods
#58788
Conversation
This file contains hidden or 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
nsajko
added
iteration
|
FTR: in another PR I'll try to reduce the
Furthermore I'll try reducing the
|
The `eltype` function was one of the few functions in the sysimage with
a `max_methods` value (the world-splitting threshold) greater than the
default. This was a workaround for the unnecessarily large number of
methods of `eltype(::Type{<:Tuple})`. The `max_methods` value was
increased in PR JuliaLang#48322 to help effect inference.
Reduce the number of `eltype(::Type{<:Tuple})` methods, which then also
allows keeping the `max_methods` for `eltype` at the default value.
The intent here is to guard against unnecessary invalidation of the
sysimage or other precompiled code, which might require decreasing the
`max_methods` value to the natural minimum for many interface
functions, by which I mean "generic function meant to have methods
added to it by package authors". I intend to approach this issue in
following PRs. See also: PR JuliaLang#57884.
Regarding future work: I consider the "natural minimum" value for
interface functions taking types to be **two**, because the bottom type
subtypes each type. If the interface function doesn't accept types, the
natural minimum should be **one**.
nsajko
force-pushed
the
decrease_method_count_for_eltype_Tuple_to_rely_on_world_splitting_less
branch
from
600869c to
2e32141
Compare
…rely_on_world_splitting_less
nsajko
added a commit
to nsajko/julia
that referenced
this pull request
Jun 27, 2025
I call callables that are meant to have methods added to by package authors "interface callables". Test that various interface callables are well-behaved in case of the introduction of a new applicable type. Only interface callables taking a single type argument are tested. The specific properties tested: * `max_methods` is high enough for good inference * the number of matching methods for a new type is not excessive The primary motivation for this change is to make any future lowering of the `max_methods` setting of the interface callables safer. To make the tests pass, fix a recent regression in base/strings/search.jl. This change depends on PR JuliaLang#58788 for `eltype`.
|
Bump. Other potential changes depend on this change, |
nsajko
added a commit
to nsajko/julia
that referenced
this pull request
Jun 27, 2025
I call callables that are meant to have methods added to by package authors "interface callables". Test that various interface callables are well-behaved in case of the introduction of a new applicable type. Only interface callables taking a single type argument are tested. The specific properties tested: * `max_methods` is high enough for good inference * the number of matching methods for a new type is not excessive The primary motivation for this change is to make any future lowering of the `max_methods` setting of the interface callables safer. To make the tests pass, fix a recent regression in base/strings/search.jl. This change depends on PR JuliaLang#58788 for `eltype`.
nsajko
added a commit
to nsajko/julia
that referenced
this pull request
Jun 27, 2025
I call callables that are meant to have methods added to by package authors "interface callables". Test that various interface callables are well-behaved in case of the introduction of a new applicable type. Only interface callables taking a single type argument are tested. The specific properties tested: * `max_methods` is high enough for good inference * the number of matching methods for a new type is not excessive The primary motivation for this change is to make any future lowering of the `max_methods` setting of the interface callables safer. To make the tests pass, fix a recent regression in base/strings/search.jl. This change depends on PR JuliaLang#58788 for `eltype`.
…rely_on_world_splitting_less
…rely_on_world_splitting_less
|
Bump. I have to note most text I wrote here on the PR discussion is only motivationally relevant for this PR. So, if you want to review, it's not really necessary to read. Also, I see Jeff Bezanson gave a thumbs-up, for what it's worth. |
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.
The
eltypefunction was one of the few functions in the sysimage with amax_methodsvalue (the world-splitting threshold) greater than the default. This was a workaround for the unnecessarily large number of methods ofeltype(::Type{<:Tuple}). Themax_methodsvalue was increased in PR #48322 to help effect inference.Reduce the number of
eltype(::Type{<:Tuple})methods, which then also allows keeping themax_methodsforeltypeat the default value.The intent here is to guard against unnecessary invalidation of the sysimage or other precompiled code, which might require decreasing the
max_methodsvalue to the natural minimum for many interface functions, by which I mean "generic function meant to have methods added to it by package authors". I intend to approach this issue in following PRs. See also: PR #57884.Regarding future work: I consider the "natural minimum" value for interface functions taking types to be two, because the bottom type subtypes each type. If the interface function doesn't accept types, the natural minimum should be one.