I considered something like your idea Erik, but what I find unfortunate is
that to write new functions for the type you need to define them for both
types, that is, both Impl1 and Impl2. Some typealias of a Union{Impl1,
Impl2} might make that smoother though.
I also didn't get your inline trick to work, in the code below, a is not
inferred but b is.
type Impl1 end
type Impl2 end
@inline Impl(N) = getImpl(Val{N})
getImpl(::Type{Val{1}}) = Impl1
getImpl(::Type{Val{2}}) = Impl2
function foo{N}(::Type{Val{N}})
a = Impl(N)
b = getImpl(Val{N})()
return a, b
end
Ben, that seems like an okay solution except I don't really like that the
internal representation leaks out to the user. I might want to completely
change the storage format at some later point (like making things stack
allocated) which would change the interface for a user.
On Saturday, February 20, 2016 at 12:34:00 AM UTC+1, Erik Schnetter wrote:
>
> To check performance, I usually look at the generated machine code
> (`code_native`). If there's a type instability, the code is a mess. I
> understand that that's not everybody's preferred method since it
> requires reading and understanding machine code...
>
> A better method would be to use `@time` and `@profile` in the usual
> manner. Inefficiencies and type instabilities should show up there.
>
> -erik
>
> On Fri, Feb 19, 2016 at 6:23 PM, Davide Lasagna <[email protected]
> <javascript:>> wrote:
> > Cool trick, thanks. I had a similar problem and ended up defining
> methods with the Val{} argument for dispatch on different values. I was not
> entirely happy with it, though, because of all the extra typing of
> parenthesis. Will try adding an inlined calling method.
> >
> > How in practice would you go checking that you do not really hit
> performance?
> >
> > Davide
>
>
>
> --
> Erik Schnetter <[email protected] <javascript:>>
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
