There exists a tension between readability and speed. This is discussed briefly in Keeping track of simple vs high-performance versions - Usage / Performance - JuliaLang . Indeed, I often write two versions of a function, V1: Naive implementation. Since Julia is so expressive, this implementation …

[image] xzackli: I’d love to hear about alternative approaches! What’s the advantage of @slow f(...) vs. f_slow(...), i.e. just renaming your function? The more complicated case, in which manual renaming doesn’t work, is when you want to call a function g(x), which calls some other functions…

I’m trying to express the idea that f and f_slow really are the same map, but with different implementations. I agree it’s not so much better than simply writing some docstring that promises this for f and f_slow. I find myself wanting a nested implementation selector pretty frequently, but it seem…

I want to add that this macro is similar in spirit to LinearAlgebra.lu, which is where I first encountered this pattern. lu(A, pivot=Val(true); check = true) -> F::LU The value type for pivot does compile-time implementation selection using the same lu name since they perform the same factorizatio…

[image] stevengj: In an ideal world, calling @slow g(x) would cause the nested call to f(x) to be replaced with the slow version, but it doesn’t sound like your macro can do this? (i.e. you’d have to change all of your function signatures to pass an implementation-selector object down the call c…

I have a piece of code that I sometimes use for this purpose, where expanded macro calls look like this: # define a "slow" variant function fun(::Val{:slow}, x, y) sleep(1) x + y end # ... and make it the default variant(::typeof(fun)) = Val(:slow) fun(x, y) = fun(variant(fun), x, y) # de…

I like your Variant approach, and it’s able to deal with nesting very well. I think if this had been a package, I probably would have been using it a fair amount. This uses the module’s method table as a mutable state, which feels a little weird to me – but probably is ok for most situations. @mari…

Slow.jl: keep around a slow implementation of your functions

General Usage

Henrique_Becker April 3, 2021, 6:28pm 8

I think this approach is similar to the one suggested for toggle-able assertions.

Topic		Replies	Views
Keeping track of simple vs high-performance versions Performance	2	1149	January 30, 2018
Why are my higher order functions a million times slower than they should be? Performance	7	827	April 26, 2022
Metaprogramming to automatically test new versions of code New to Julia metaprogramming	9	411	February 16, 2025
Significant difference in execution speed between similar functions with nested loops Performance question	4	274	March 8, 2023
How to alias a function to have maximum speed New to Julia	8	592	January 14, 2023

Slow.jl: keep around a slow implementation of your functions

Related topics