How to avoid vectors of abstract types?

General Usage Performance
1

Hello,

I started using Julia intensively a few months ago, and I keep coming across situations where I have vectors of abstract types, which should be avoided for performance reasons. I can’t seem to find satisfying solutions to these situations.

Here is a simplified example of the last time I had this problem:

I’m doing some machine learning experiments, during which I log several metrics, which number and type can differ between experiments. For this, I define an AbstractMetric abstract type, and, for each metric, one concrete type I can dispatch on. For example:

# Abstract type
abstract type AbstractMetric end

function log!(m::AbstractMetric; kwargs...)
    push!(m.history, m(kwargs...))
end

# Loss concrete types
struct Loss <: AbstractMetric
    history::Vector{Float64}
end

Loss() = Loss(Float64[])

function (m::Loss)(; loss, groundtruths, predictions, kwargs...)
    return sum(loss(y, y_pred) for (y, y_pred) in zip(groundtruths, predictions))
end

# Accuracy concrete type
struct Accuracy <: AbstractMetric
    history::Vector{Float64}
end

Accuracy() = Loss(Float64[])

function (m::Accuracy)(; groundtruths, predictions, kwargs...)
    return mean(y == y_pred for (y, y_pred) in zip(groundtruths, predictions))
end

# Other metrics
...

I store all the current metrics in a vector and use a for loop calling the log! method.

Problem: the vector is a Vector{AbstractMetric}.
Is there a better implementation that can avoid that ?

2

if the length is expected to be small, use a Tuple

2 Likes
3

Yeah, there are a lot of performance problems that could be avoided if people used tuples instead of arrays and namedtuples instead of dicts for small arrays and dicts…

4

Have you actually determined that this is an issue, by profiling? If not, then unless one iteration of your training loop is extremely fast then I doubt the overhead from dynamic dispatch is adding much.

1 Like
5

Thank you !
Tuple seems the way to go here, didn’t think of that.

6

I’m not sure this in particular is an issue, but profiling shows that metrics computation currently take about 70% of the training loop time. That’s why I’m trying to solve potential performance issues.