# Slow \`convert\` for arrays. Use multiple dispatch instead?

**URL:** <https://discourse.julialang.org/t/slow-convert-for-arrays-use-multiple-dispatch-instead/63822>\
**Category:** Performance\
**Tags:** arrays, convert\
**Created:** [June 30, 2021, 11:42am UTC](https://discourse.julialang.org/t/slow-convert-for-arrays-use-multiple-dispatch-instead/63822 "2021-06-30T11:42:47Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![manuelbb-upb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/manuelbb-upb/32/25222_2.png) [@manuelbb-upb](https://discourse.julialang.org/u/manuelbb-upb)\
**Post date:** [June 30, 2021, 11:42am UTC](https://discourse.julialang.org/t/slow-convert-for-arrays-use-multiple-dispatch-instead/63822/1 "2021-06-30T11:42:47Z")

</div>

I was wondering why something like

```julia
x = rand(10)
convert(Vector{Float64}, x)

```

is relatively slow, when `x` does not even need to be converted.

I noticed that [in Julia base](https://github.com/JuliaLang/julia/blob/71bf60858ee2dcf219f6de568f712a0ab3756549/base/array.jl#L554) the `convert` method is defined as

```julia
convert(::Type{T}, a::AbstractArray) where {T<:Array} = a isa T ? a : T(a)

```

At least for converting some `a :: Array` I would rather do something like

```julia
convert(::Type{T}, a :: T) where T<:Array = a

```

I am sure that I’m overlooking some subtleties concerning the type hierarchy here.  
But taking

```julia
std_convert(::Type{T}, a::AbstractArray) where {T<:Array} = a isa T ? a : T(a)

new_convert(::Type{T}, a::T) where{T<:Array} = a
new_convert(::Type{T}, a::F) where{T<:Array, F<:AbstractArray} = T(a)

x = rand(10)

```

leads to a significant speedup when no conversion has to be done

```julia
julia> @btime std_convert( Vector{Float64}, x )
  115.684 ns
julia> @btime new_convert( Vector{Float64}, x )
  3.851 ns

```

… and equal performance otherwise:

```julia
julia >@btime std_convert( Vector{Float32}, x )
  162.644 ns (1 allocation: 128 bytes)
julia> @btime new_convert( Vector{Float32}, x )
  152.948 ns

```

I would appreciate any comment on whether the `new_convert` way is sensible 🙂

---

<div class="post-metadata">

**Author:** ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)\
**Post date:** [June 30, 2021, 11:52am UTC](https://discourse.julialang.org/t/slow-convert-for-arrays-use-multiple-dispatch-instead/63822/2 "2021-06-30T11:52:54Z")

</div>

> [@manuelbb-upb](#):
>
> `x = rand(10)`

Use `const x = ...` and there is no difference (see [Performance Tips - Avoid (non-constant) global variables](https://docs.julialang.org/en/v1/manual/performance-tips/#Avoid-global-variables)).

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [June 30, 2021, 12:16pm UTC](https://discourse.julialang.org/t/slow-convert-for-arrays-use-multiple-dispatch-instead/63822/3 "2021-06-30T12:16:06Z")

</div>

> [@fredrikekre](#):
>
> Use `const x = ...` and there is no difference

Or simply [interpolate global variables](https://juliaci.github.io/BenchmarkTools.jl/dev/manual/#Interpolating-values-into-benchmark-expressions) when benchmarking to avoid the dynamic-dispatch overhead, i.e. use `@btime std_convert( Vector{Float64}, $x )`

---

<div class="post-metadata">

**Author:** ![manuelbb-upb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/manuelbb-upb/32/25222_2.png) [@manuelbb-upb](https://discourse.julialang.org/u/manuelbb-upb)\
**Post date:** [June 30, 2021, 1:09pm UTC](https://discourse.julialang.org/t/slow-convert-for-arrays-use-multiple-dispatch-instead/63822/4 "2021-06-30T13:09:27Z")

</div>

Thank you both!  
I totally forgot that I was operating in global scope. Silly me.

When actually testing functions using either method there is no difference.