@Steven,
Would you help me to understand the difference between this case here and
the case of DataArray{T}s -- which, by my understanding, are basically
AbstractArray{Union{T, NaN}, 1}'s? My first thought was that taking a
Union{Bool, AbstractArray{Float, 2}} argument would potentially interfere
with the compiler's ability to perform type inference, similar to how
looping through a DataArray can experience a cost from the compiler having
to deal with possible NaNs.
But what you're saying is that this does not apply here, since presumably
the argument, whether it is a Bool or an AbstractArray, would be
type-stable throughout the functions operations -- unlike the values
contained in a DataArray. Would it be fair to say that dealing with Union{}
types tends to be dangerous to performance mostly when they are looped over
in some sort of container, since in that case it's not a matter of simply
dispatching a specially compiled method on one of the conjunct types or the
other?
On Friday, May 29, 2015 at 9:49:45 PM UTC-4, Steven G. Johnson wrote:
>
> *No!* This is one of the most common misconceptions about Julia
> programming.
>
> The type declarations in function arguments have *no impact* on
> performance. Zero. Nada. Zip. You *don't have to declare a type at
> all* in the function argument, and it *still* won't matter for
> performance.
>
> The argument types are just a filter for when the function is applicable.
>
> The first time a function is called, a specialized version is compiled for
> the types of the arguments that you pass it. Subsequently, when you call
> it with arguments of the same type, the specialized version is called.
>
> Note also that a default argument foo(x, y=false) is exactly equivalent to
> defining
>
> foo(x,y) = ...
> foo(x) = foo(x, false)
>
> So, if you call foo(x, [1,2,3]), it calls a version of foo(x,y)
> specialized for an Array{Int} in the second argument. The existence of a
> version of foo specialized for a boolean y is irrelevant.
>
