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.

Sign up for GitHub

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

Jump to bottom

slowdown in methods(hvcat) #41518

Closed
JeffBezanson opened this issue Jul 8, 2021 · 3 comments · Fixed by #41925
Closed

slowdown in methods(hvcat) #41518

JeffBezanson opened this issue Jul 8, 2021 · 3 comments · Fixed by #41925
Labels
compiler:latency Compiler latency regression Regression in behavior compared to a previous version types and dispatch Types, subtyping and method dispatch

Comments

@JeffBezanson
Copy link
Member

After #41394, the call methods(hvcat, (Tuple{Int,Int},Any,Any,Any,Any,Any,Any,Int,Int)) takes over 50 seconds instead of less than 1 second. Most likely due to subtyping of lots of unions and long argument lists.
@JeffBezanson JeffBezanson added regression Regression in behavior compared to a previous version types and dispatch Types, subtyping and method dispatch compiler:latency Compiler latency labels Jul 8, 2021
@dkarrasch
Copy link
Member

Is this improved/resolved by #41511? Probably not.

@JeffBezanson
Copy link
Member Author

I checked; unfortunately not.

@dkarrasch
Copy link
Member

That reminds me of a massive observed slowdown when I was extending concatenation of LinearMaps toward AbstractMatrix, JuliaLinearAlgebra/LinearMaps.jl#71. Unfortunately, I forgot how it got resolved eventually, probably by pure luck, because I didn't know how to inspect the problem more thoroughly.

vtjnash added a commit that referenced this issue Aug 18, 2021
@vtjnash
ml-matches: fix performance trap
a93c809 
While normally we try to only call `jl_type_morespecific` on types with
a non-empty intersection (to be more precise about ambiguity reporting),
the only work we would do here (if the intersect is empty) would also be
to call continue.

Fixes #41518
@vtjnash vtjnash mentioned this issue Aug 18, 2021
Merged
vtjnash added a commit that referenced this issue Aug 24, 2021
@vtjnash
ml-matches: fix performance trap (#41925)
e7995e4 
While normally we try to only call `jl_type_morespecific` on types with
a non-empty intersection (to be more precise about ambiguity reporting),
the only work we would do here (if the intersect is empty) would also be
to call continue.

Fixes #41518
LilithHafner pushed a commit to LilithHafner/julia that referenced this issue Feb 22, 2022
@vtjnash @LilithHafner
ml-matches: fix performance trap (JuliaLang#41925)
6ec761a 
While normally we try to only call `jl_type_morespecific` on types with
a non-empty intersection (to be more precise about ambiguity reporting),
the only work we would do here (if the intersect is empty) would also be
to call continue.

Fixes JuliaLang#41518
LilithHafner pushed a commit to LilithHafner/julia that referenced this issue Mar 8, 2022
@vtjnash @LilithHafner
ml-matches: fix performance trap (JuliaLang#41925)
0951eab 
While normally we try to only call `jl_type_morespecific` on types with
a non-empty intersection (to be more precise about ambiguity reporting),
the only work we would do here (if the intersect is empty) would also be
to call continue.

Fixes JuliaLang#41518
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler:latency Compiler latency regression Regression in behavior compared to a previous version types and dispatch Types, subtyping and method dispatch
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

ml-matches: fix performance trap JuliaLang/julia
2 participants
@JeffBezanson @dkarrasch