Immensely slow Axis creation with xticks of small values

[wsshin]

MWE:

using CairoMakie

fig = Figure()

@time Axis(fig)
@time Axis(fig, xticks=1e0:2e0:10e0)
@time Axis(fig, xticks=1e6:2e6:10e6)
@time Axis(fig, xticks=1e-6:2e-6:10e-6)

Result:

  0.009013 seconds (46.80 k allocations: 2.994 MiB)
  0.009907 seconds (47.16 k allocations: 3.017 MiB)
  0.007848 seconds (45.38 k allocations: 2.930 MiB)
  1.619856 seconds (53.13 k allocations: 689.011 MiB, 50.31% gc time)
Axis with 0 plots:

Version info:

julia> VERSION
v"1.7.2-pre.0"

(@v1.7) pkg> st Makie
      Status `~/.julia/environments/v1.7/Project.toml`
  [ee78f7c6] Makie v0.18.3

[jkrumbiegel]

Have you profiled this to see where the time is spent?

[ffreyer]

https://github.com/MakieOrg/Makie.jl/blob/e77516d073a8b3a0b8af93583dbdf841199b07b7/src/makielayout/lineaxis.jl#L245

This array contains 9999994 values with the last example. Rather than 6 for 1e0:2e0:10e0 or 0 for 1e6:2e6:10e6. Both e6 and e-6 fail to generate correct ticks (no ticks, overlapping ticks). Probably more Float32 issues?

[ffreyer]

Is there anything stopping use from having the whole tick calculation run with Float64/Point2{Float64} and converting to 32 bit floats at the end, i.e. in plot! calls?

[ffreyer]

https://github.com/MakieOrg/Makie.jl/blob/e77516d073a8b3a0b8af93583dbdf841199b07b7/src/makielayout/lineaxis.jl#L741-L747

More specifically, this block has 1.0000001f-5 : 1.0000001f-6 : 10.0f0 as the final range. The vmax comes from limits, which are still the default (0, 10).

[jkrumbiegel]

No I don't think anything's stopping us, to be honest most of that stuff is from the very beginning where I thought everything in Makie had to be Float32 so it needs an overhaul

[wsshin]

Does that mean that now it is OK to change all Float32 occurrences in Makie to Float64. That sounds like a simple change to me, but I guess I'm probably wrong...

[jkrumbiegel]

No :) it just means that there are more Float32's around than necessary. A lot of these can be changed in principle, but a lot of them are still necessary for GLMakie/WGLMakie and would require a rewrite of the backend-dependent conversion logic.

[ffreyer]

The problem here isn't Float32, it's that ticks and limits don't synchronize early. That results in a range of 1e-5:1e-6:10 valid tick positions (?) in the snippet above, which is a big array.