Avoiding runtime dispatch is perhaps the #1 optimization advice in Julia forums. As I understand it, the reason is that when the Julia compiler does a runtime dispatch it does not at compile-time neccesarily know the return type of the function to be called. And so, it needs to allocate space for t…

Note that there’s an escape hatch for changing max_methods if the code requires: julia/base/experimental.jl at 96866cb8f5c8f28d96c2b9e4eb1ec4f3a00a705b · JuliaLang/julia · GitHub

Here’s a more relevant issue: Function with four or more method definitions has unstable return type opened 04:34AM - 11 Aug 17 UTC (UTC) [wsshin] wsshin …

Thx Matt - yes, I know the invalidation argument - and I know the Julia community has spent probably hundreds of man-years in a combined effort to reduce invalidations and reduce TTFX - to great success! And reducing invalidations/TTFX is good - but in this case it results in suboptimal “production…

The answer is that it’s a tradeoff. See the table in the linked issue evaluating different algorithms and the tradeoffs therein. There are obviously different winners and losers in any tradeoff, and there are obviously different workloads that’ll win or lose in any given choice. Note that with ma…

Fixing boxing of immutable isbits (mutable args are already boxed) arguments during dynamic dispatch seems feasible. As the PR linked to the GH issue you shared shows though, it’d require major internal plumbing work. I suspect you could count the number of people able to do such work in this commun…

:exploding_head: What does @max_methods(n::Int, fdef::Expr) require to move outside from the Experimental module?

This is absolutely brilliant! Using this, the allocation disappears and the @btime drops 75%. This will solve - if not all - then a lot of my worries. Thank you Keno!!

Sorry for chiming in late. In a similar situation, I once thought that it would be great if one could give additional return type information to the compiler. In the setting of the OP, I’m thinking of something like @declare_return_type f(::AbstractFoo)::Float64 Such a statement would promise tha…

Check out this conversation [image] Specifying Function Contract Internals & Design There is lots of good work around specifying the interface of types, their traits, etc. I was curious if I’m missing conversation around declaring the behavior of a function in terms of it…

The thread you’ve mentioned seems to discuss the idea from the perspective of enforcing interfaces, not as a means to avoid runtime dispatch. Has the latter been considered anywhere?

Well, if you used the declaration mechanism to declare that the function always returns a certain type, then all implementations would have to return that type. But also, I think you can already do what you’re talking about with FunctionWrappers.jl, no? Edit: without enforcing the return type for …

Elimination of (unnecessary) runtime dispatch allocations

Internals & Design

mrufsvold May 4, 2024, 10:11pm 10

Check out this conversation

Topic		Replies	Views
Why does runtime dispatch allocate when the return type is inferred? Internals & Design memory-allocation , runtime-dispatch	5	297	May 17, 2025
Multiple dispatch with more than 4 methods blocks type inference Performance	15	1474	October 28, 2020
Why does this type instability lead to allocations? Performance	3	590	January 13, 2023
Disabling allocations Performance	50	6094	December 10, 2020
Performance problems when dealing with deliberately type-unstable code. How to use type knowledge better? Performance	33	2318	December 30, 2020

Elimination of (unnecessary) runtime dispatch allocations

Related topics