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

fix specificity of sigs that are strict subtypes of vararg sigs #18917

Merged
merged 1 commit into from
Oct 14, 2016

Conversation

JeffBezanson
Copy link
Sponsor Member

@JeffBezanson JeffBezanson commented Oct 14, 2016

I noticed that the Array constructor

(::Type{Array{T,N}}){T,N}(d::Vararg{Int, N})

was getting called in preference to

(::Type{Array{T,1}}){T}(m::Int)

which cased extra tuple allocations. The problem seems to be method specificity when one signature is Vararg, and the other is a specialization of it (e.g. for the case N==1 as here). This patch should fix it.

Fix #18922

@JeffBezanson JeffBezanson added performance Must go faster types and dispatch Types, subtyping and method dispatch backport pending 0.5 bugfix This change fixes an existing bug labels Oct 14, 2016
@timholy
Copy link
Sponsor Member

timholy commented Oct 14, 2016

Worth checking whether this fixes #3025, #10174, #13651, and perhaps others.

@JeffBezanson
Copy link
Sponsor Member Author

This is very specific to varargs with bound length parameters, so I don't think it will fix any of those.

@JeffBezanson JeffBezanson merged commit 51e9247 into master Oct 14, 2016
@tkelman tkelman deleted the jb/varargspecificity branch October 14, 2016 17:16
@tkelman
Copy link
Contributor

tkelman commented Oct 15, 2016

8a376a0 should be included with the backport

tkelman pushed a commit that referenced this pull request Feb 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix This change fixes an existing bug performance Must go faster types and dispatch Types, subtyping and method dispatch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1D array allocation is using jl_new_array
3 participants