Is UnionAll abstract? Is it bad for performance?

General Usage Performance
1

Sorry in advance if this is covered somewhere; I’m still a beginner.

I’m concerned about the two performance tips as they relate to UnionAll: 1) Avoid fields with abstract type and 2) Avoid containers with abstract type parameters. Let’s say we have some type:

mutable struct MyType{field_type1<:Abstract_field_type, field_type2<:Abstract_field_type}
    a::field_type1
    b::field_type2
    ...
end

Where there are a few possible concrete types of Abstract_field_type. Now I want to contain a MyType object in a different object or in a dictionary of MyType objects:

mutable struct container_struct
    a::MyType
    b::Dict{Int64, MyType}
end

Now when I try to see if the values of the dict b are an abstract type, by setting container = container_struct(...) and printing: println(valtype(container.b).abstract), I get type UnionAll has no field abstract. Is a UnionAll abstract? Might this cause a performance hit? Or is UnionAll covered under this blogpost: Union-splitting: what it is, and why you should care when it says

But often, Union{Type1, Type2, ...} is nothing to worry about, because it causes little or no performance hit of any kind.

If this is a potential performance problem, how can I design things better? Thank you!

2

Yes, UnionAll is abstract.

if your container struct and dict only hold one particular subtype of that UnionAll you can do

mutable struct container_struct{T<:MyType}
    a::T
    b::Dict{Int64, T}
end

Otherwise, you can just leave it as you have it if you need a hetrogenious container.
It’s not the end of the world.
We don’t have to scrape every last bit of peformance out.

You can put in function barriers where you need them

5 Likes