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.
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.
In your code you can change the length
type annotation from Real
to Int
for example.
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.
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.
Thank you both. I forgot to mention that precompilation time was another variable that I want to consider.
Does the large mutable struct create precompilation latency?
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/
This post is in my sticky notes for "Read this!" since yesterday hehe
What's the selling point of the new plotting package?
:silence:
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