top | item 45520348

(no title)

__atx__ | 4 months ago

I do wonder in particular about the startup time "time-to-plot" issue. I last used Julia about 2021-ish to develop some signal processing code, and restarting the entire application could have easily taken tens of seconds. Both static precompilation and hot reloading were in early development and did not really work well at the time.

discuss

order

pavon|4 months ago

On a 5 year old i5-8600, with Samsung PM871b SSD:

  $ time julia -e "exit"
  real    0m0.156s
  user    0m0.096s
  sys     0m0.100s

  $ time julia -e "using Plots"
  real    0m1.219s
  user    0m0.981s
  sys     0m0.408s

  $ time julia -e "using Plots; display(plot(rand(10)))"
  real    0m1.581s
  user    0m1.160s
  sys     0m0.400s
Not a super fair test since everything was already hot in i/o cache, but still shows how much things have improved.

j_maffe|4 months ago

That was fixed in 1.9. Indeed it makes a huge difference now that you can quickly run for the first time.

jakobnissen|4 months ago

This was absolutely not "fixed" in 1.9, what are you talking about. It was improved in 1.9, but that's it. Startup time is still unacceptably slow - still tens of seconds for large codebases.

Worse, there are still way too many compilation traps. Splatted a large collection into a function? Compiler chokes. Your code accidentally moves a value from the value to the type domain? You end up with millions of new types, compiler chokes. Accidentally pirate a method? Huge latency. Chose to write type unstable code? Invalidations tank your latency.

moelf|4 months ago

on a macMini (i.e. fast RAM), time to display:

- Plots.jl, 1.4 seconds (include package loading)

- CairoMakie.jl, 4 seconds (including package loading)

julia> @time @eval (using Plots; display(plot(rand(3))))

  1.477268 seconds (1.40 M allocations: 89.648 MiB, 2.70% gc time, 7.16% compilation time: 5% of which was recompilation)