Are large mutable struct "bad"? · helpdesk (published)

For the efficiency seekers. I'm developing a plotting package, and for the code design, I'm creating a collection for mutable structs in order to store "all" styling information about the plot. For example:

@with_kw mutable struct Axis
    length::Real
    lims::Tuple{Real,Real}
    color::Color = parse(Colorant, "gray")
    scale::Symbol = :linear
    linethickness::Real = 1
    style::String = "solid"

    majorticks::Ticks = Ticks()
    minorticks::Ticks = Ticks(; qtd=0, tickthickness=0.25, length=2)

    label::Union{String,LaTeXString} = ""
    # using underscore to avoid chocking with Luxor function `fontsize`
    font_size::Real = 10
    font_family::String = "Roboto Light"
    labelangle::Real = 0
    labelcolor::Color = parse(Colorant, "gray")

    # Drawing fields
    startpoint::Point = O
    endpoint::Point = O
    startarrow::Bool = false
    finisharrow::Bool = false
    arrowheadlength::Real = 10
end

I'm wondering if this will cause bad performance, or if it's a bad design for Julia.
My idea was to apply functions in order to set these properties, and then a separate function to draw it.
In the first iteration of the code, I was placing these properties as arguments in the drawing functions. But I changed my mind, since some of these attributes are reused.

Elias Carvalho (Jan 26 2022 at 13:30):

I don't think so, as some packages use it.
A performance issue in structs are fields with abstract type annotation.
That is, if you can avoid abstract type annotation in struct fields, do so.

Elias Carvalho (Jan 26 2022 at 13:34):

In your code you can change the length type annotation from Real to Int for example.

Andrey Oskin (Jan 26 2022 at 13:56):

There was a nice article of Chris Rackauckas regarding optimizations. One of the key ideas was that you should optimize only things that require optimization. Ask yourself: how often this function is called in a usual application? If it is intended to be called thousands or millions of times per second, then yes, you should optimize it as much as possible.

If you call it once per few minutes and it's execution time is milliseconds, you shouldn't care about optimization at all.

Andrey Oskin (Jan 26 2022 at 13:57):

Well, of course there are also compile time efficiency (with strict types your function is going to be compiled once), but this is a different thing.

Davi Sales Barreira (Jan 26 2022 at 13:57):

Thank you both. I forgot to mention that precompilation time was another variable that I want to consider.

Davi Sales Barreira (Jan 26 2022 at 13:58):

Andrey Oskin (Jan 26 2022 at 14:02):

I doubt that (but I am not an expert). Most of the precompile time is related to method invalidation, as far as I know.

Davi Sales Barreira (Jan 26 2022 at 14:10):

jar (Jan 27 2022 at 02:01):

Davi Sales Barreira (Jan 27 2022 at 13:16):

Filippos Christou (Mar 26 2022 at 16:31):

I don't know what the depth of your plotting package is, but did you consider developing your package as a Makie recipy ?
For example this styling Information you mentioned could be Makie attributes.

Stream: helpdesk (published)

Topic: Are large mutable struct "bad"?

Davi Sales Barreira (Jan 26 2022 at 13:25):