Stream: helpdesk (published)

Topic: Are large mutable struct "bad"?


view this post on Zulip Davi Sales Barreira (Jan 26 2022 at 13:25):

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.

view this post on Zulip 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.

view this post on Zulip Elias Carvalho (Jan 26 2022 at 13:34):

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

view this post on Zulip Kwaku 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.

view this post on Zulip Kwaku 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.

view this post on Zulip 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.

view this post on Zulip Davi Sales Barreira (Jan 26 2022 at 13:58):

Does the large mutable struct create precompilation latency?

view this post on Zulip Kwaku 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.

You can read more about that in Tim Holy blog: https://julialang.org/blog/2021/01/precompile_tutorial/

view this post on Zulip Davi Sales Barreira (Jan 26 2022 at 14:10):

This post is in my sticky notes for "Read this!" since yesterday hehe

view this post on Zulip jar (Jan 27 2022 at 02:01):

What's the selling point of the new plotting package?

view this post on Zulip Davi Sales Barreira (Jan 27 2022 at 13:16):

:silence:

view this post on Zulip 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.


Last updated: Nov 06 2024 at 04:40 UTC