# Roadmap for a faster time-to-first-plot?

**URL:** <https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956>\
**Category:** Internals & Design\
**Tags:** ttfp\
**Created:** [April 9, 2019, 1:22pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956 "2019-04-09T13:22:42Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [April 10, 2019, 8:19am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/41 "2019-04-10T08:19:01Z")

</div>

I’m just going to expand slightly on my previous post.

It’s possible to be reasonably sophisticated in some aspects of programming, and yet be a ‘total rube’ in others. For myself, I’m comfortable with parametric types, type stability, generic programming, etc. etc. But I’m very _uncomfortable_ with concepts such as package management, integrated testing, git wrangling, and userimg.jl

So even though someone might in some cases be literally looking at the screen and going “you have to show me which button to push”, they could still be capable of exploiting many of the strengths of Julia, and in fact be chafing against limitations in other languages.

Perhaps I’m going off-topic here (sorry about that). The relevance to this thread might be to highlight that even some “sophisticated” users can still use some hand-holding or need certain tools to be easier to use.

---

<div class="post-metadata">

**Author:** ![jonathanBieler](https://avatars.discourse-cdn.com/v4/letter/j/82dd89/32.png) [@jonathanBieler](https://discourse.julialang.org/u/jonathanBieler)\
**Post date:** [April 10, 2019, 8:19am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/42 "2019-04-10T08:19:32Z")

</div>

If the PackageCompiler path is a solution then ideally it should be made dead simple to use, having to know what userimg is or how to build Julia from source won’t do it for most people (for example I don’t know how any of these things, and I’m a relatively experienced user).

But from some of the comments above it looks like it’s not even clear if the PackageCompiler is a good solution, has someone made some systematic benchmarks ? For example compile Plots, DataFrames, Distributions, etc. and compare the timings for common use cases.

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [April 10, 2019, 8:27am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/43 "2019-04-10T08:27:48Z")

</div>

Just a couple of comments for people who are interested in this issue:

- if you want to find out what’s taking the most time, it’s pretty easy to diagnose via profiling. For example, `ProfileView.view(C=true)` will tell you pretty clearly what fraction of the time is spent in inference vs LLVM.
- if you’re using a pretty recent master/nightly of Julia, [SnoopCompile](https://github.com/timholy/SnoopCompile.jl) now provides an easy way to measure inference time (`@snoopi`) as well as “core compilation” time (`@snoopc`).
- One doesn’t have to wait for Jeff/Jameson/Keno to do something about this. For example, my measurements suggest that for packages I care about, much of the problem is due to the fact that some methods simply don’t get stored in the precompile cache file. There’s a start on a fix at [https://github.com/JuliaLang/julia/pull/31466](https://github.com/JuliaLang/julia/pull/31466) ; I’ve been too short on time lately to finish it, but anyone comfortable with C has a shot at fixing this. Via a private email exchange, Jameson has kindly offered to tutor me through the final stages via google hangouts; I bet that if someone else from the community wanted to pick this up he’d extend the same offer.

---

<div class="post-metadata">

**Author:** ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)\
**Post date:** [April 10, 2019, 8:33am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/44 "2019-04-10T08:33:35Z")

</div>

> [@Tamas\_Papp](#):
>
> someone (ideally a TA, or someone from IT, but practically at this point the instructor 😉) should set up a precompiled system image

We’re not talking about courses, which are in a controlled environment, but undergraduate/masters/PhD research projects. The students need to use their own computers, so “precompiled system image” is impossible. They also need to add and modify packages as their research dictates. They are also on a deadline, so latency issues are serious (to them).

> [@jonathanBieler](#):
>
> But from some of the comments above it looks like it’s not even clear if the PackageCompiler is a good solution, has someone made some systematic benchmarks ? For example compile Plots, DataFrames, Distributions, etc. and compare the timings for common use cases.

It’s not systematic but I did manage to PackageCompiler Plots+GR, though with some headaches on the way ([Plots+GR failed · Issue #215 · JuliaLang/PackageCompiler.jl · GitHub](https://github.com/JuliaLang/PackageCompiler.jl/issues/215)). It actually does solve the time-to-plot problem: `using Plots` is instantaneous (in the eyeball norm) and `plot(1:10)` takes only a second or so, which feels like booting up GKS.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 10, 2019, 8:37am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/45 "2019-04-10T08:37:03Z")

</div>

> [@dlfivefifty](#):
>
> They are also on a deadline, so latency issues are serious (to them).

All issues are “serious” to everyone affected. At this point, they can 1) live with the issue, 2) set up a precompiled image, 3) contribute to Julia to make this better.

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [April 10, 2019, 1:58pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/46 "2019-04-10T13:58:00Z")

</div>

I probably fit @DNF 's description of someone who knows a lot about a little and I think this sort of thing is the solution. We all have a lot of opinions based on a very diverse set of needs. I don’t think it’s realistic to expect the handful of very talented and intelligent developers to actually solve these problems in a way that is pleasing to everyone. I’d think we really need leaders in our respective fields to identify core issues in these fields and establish a lot of user friendly solutions. I don’t know if it’s possible for one catch all solution, but maybe it’s possible to have a handful of solutions that cover a limited set of problems individually.

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [April 10, 2019, 3:55pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/47 "2019-04-10T15:55:04Z")

</div>

> [@dlfivefifty](#):
>
> We’re not talking about courses, which are in a controlled environment, but undergraduate/masters/PhD research projects. The students need to use their own computers, so “precompiled system image” is impossible.

What we ended up doing last year was setting up and tweaking a jupyterhub setup for the graduate students. Basically, bypassing any local installation at all so we could keep things stable, precompile a set of packages, etc… Right now an RA is trying to get this stuff built into the jupyterhub with the package compiler, which would help plenty. The environment is not really controlled, but acts as a stable baseline.

The students loved it, and it made julia far more accessible (i.e. these are students who are great at matlab but probably have opened up a terminal a half dozen times in their lives, and certainly have no idea what a dotfile is). That type of user is much more comfortable in a jupyter-only environment for a while, and it can take them pretty far.

Of course, this only works for an individual researcher if you university has the resources to run the hardware/support for a big jupyterhub installation.

---

<div class="post-metadata">

**Author:** ![jeff.bezanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeff.bezanson/32/48_2.png) [@jeff.bezanson](https://discourse.julialang.org/u/jeff.bezanson)\
**Post date:** [April 10, 2019, 8:40pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/48 "2019-04-10T20:40:23Z")

</div>

Realistic or not, I _do_ think it is possible to mostly solve this! We have not yet even attempted any of the known-possible solutions most likely to give huge latency improvements. This is not a situation where we are out of ideas. But, I do recommend that people invest in workarounds like custom system images in the short term.

> [@asprionj](#):
>
> AFAIK there has been a huge leap into this direction with the new debugger (based on an interpreter, I guess) – correct me if I’m wrong. You could, for example, always use the interpreter for the first evaluation of something, and start compiling it right away in the background. And/or let the user completely disable compilation if he’s (currently) working very interactively (and the working pace of humans is way slower than an interpreter).

You can already disable compilation by starting julia with `--compile=min`. We have actually always had an interpreter, which we use e.g. for simple top-level expressions. Yes, using it more is just the sort of thing we need to explore to slay the latency dragon.

---

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [April 10, 2019, 11:11pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/49 "2019-04-10T23:11:19Z")

</div>

> [@jeff.bezanson](#):
>
> I do recommend that people invest in workarounds like custom system images in the short term.

If I understand correctly building custom system images smoothly also require some improvements in core `julia`.

I think a big obstacle for creating custom system images is ` __init__ `. It has to be executed for each package because it might be needed for executing the top-level statements of the downstream packages (e.g., using PyCall functions to compute some constants). However, ` __init__ ` may setup some global mutable state that is assumed to start from “empty” state (e.g., using `push!`). This assumption is invalid after the packages are compiled into the system image. It would be nice if `--output-o` supports loading from precompile cache files so that packages are loaded in the same way as normal usage. This way, ` __init__ ` does not have to be called in the Julia process with `--output-o` compiling the system image. IIUC this is not how it’s done at the moment (and that’s why PackageCompiler is manually calling ` __init__ `). Is it correct? If so, is it possible to change it?

If it is difficult/impossible or it does not make sense to slow down improving the compiler, I think some package authors need to learn some tricks to make their packages work with PackageCompiler (e.g., clear out mutable state in `atexit`).

---

<div class="post-metadata">

**Author:** ![mcreel](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mcreel/32/30088_2.png) [@mcreel](https://discourse.julialang.org/u/mcreel)\
**Post date:** [April 11, 2019, 5:33am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/50 "2019-04-11T05:33:09Z")

</div>

This is a fairly relevant case, I think, and it is the case that I have experienced when teaching. First year grad students may be exposed to Julia in their course work. The things they will be doing are fairly simple, and are known ahead of time. If one could provide them with a system image that has the common tasks already compiled, or clear, easy to execute instructions to achieve this, they would get a more favorable initial impression. When they get to more innovative work later in their studies, they would already understand that occasionally needing to wait a bit for compilation is not that big of a deal. Actually, I really don’t care much about latency in my research work, I’m used to it. It gives me time to think about what I’m doing!

---

<div class="post-metadata">

**Author:** ![jocklawrie](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jocklawrie/32/33616_2.png) [@jocklawrie](https://discourse.julialang.org/u/jocklawrie)\
**Post date:** [April 11, 2019, 6:15am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/51 "2019-04-11T06:15:09Z")

</div>

To throw another use case for low latency into the mix: serverless containers.

I have some scientific code that I put behind an HTTP server. The server is always up and I have to maintain it, which I’d rather not have to think about. It’d be nice to containerize the code and deploy to a serverless container solution such as Google Cloud Run. But this requires low latency. Rewriting the code in Python would cause an unacceptable drop in performance, and rewriting in C++ is more work than maintaining the existing server.

Seems like PackageCompiler.jl already does the job, which is great. This is just another data point for making the tool more usable.

---

<div class="post-metadata">

**Author:** ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)\
**Post date:** [April 11, 2019, 6:28am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/52 "2019-04-11T06:28:48Z")

</div>

Here’s an easy short term solution: prebuild Plots.jl and GR.jl in JuliaPro. This of course won’t solve my problems, but will solve 95% of the “new user” problems. Is that feasible?

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [April 11, 2019, 1:47pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/53 "2019-04-11T13:47:26Z")

</div>

> [@dlfivefifty](#):
>
> Here’s an easy short term solution: prebuild Plots.jl and GR.jl in JuliaPro

The issue with this for new users is the nonstandard registry JuliaPro uses. It doesn’t take long before you start requiring students to use a package not in the registry, or at least at the correct version. Tried it and it was a disaster.

---

<div class="post-metadata">

**Author:** ![avik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/avik/32/17_2.png) [@avik](https://discourse.julialang.org/u/avik)\
**Post date:** [April 11, 2019, 3:48pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/54 "2019-04-11T15:48:16Z")

</div>

The JuliaPro registry contains all packages in General, not a subset. However, versions are frozen at a certain point. So newly tagged packages and versions are not available, until the the registry is updated. Updates happen every 2-3 months.

It is possible to switch JuliaPro to use the General registry. Once you switch, however you cannot (should not) switch back.

---

<div class="post-metadata">

**Author:** ![bjarthur](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bjarthur/32/9638_2.png) [@bjarthur](https://discourse.julialang.org/u/bjarthur)\
**Post date:** [April 14, 2019, 3:13am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/55 "2019-04-14T03:13:13Z")

</div>

what’s the difference between PackageCompiler and putting `using` in userimg.jl? in terms of the resulting performance.

---

<div class="post-metadata">

**Author:** ![sdanisch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sdanisch/32/1406_2.png) [@sdanisch](https://discourse.julialang.org/u/sdanisch)\
**Post date:** [April 15, 2019, 1:35pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/56 "2019-04-15T13:35:36Z")

</div>

As I pointed out, it’s not that much - but may vary depending on your package.  
You can test it like this:

```julia
>@time using Makie # or any other library
 4.357982 seconds
>@time display(scatter(rand(6)))
35.448926 seconds

```

If you put `using Makie` into the userimg, the `using Makie` time will basically go to 0, but you’ll still need to compile any new function call to Makie.  
So in this case, you’d get a speed up of ~1.14x - but note, that the more functions you call, the more gets compiled, the smaller the speed up will get 😉  
Calling 3 more Makie functions, I’m already at only `1.11x` speed up.

---

<div class="post-metadata">

**Author:** ![mkborregaard](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkborregaard/32/556_2.png) [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)\
**Post date:** [April 15, 2019, 2:11pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/57 "2019-04-15T14:11:28Z")

</div>

> [@Tamas\_Papp](#):
>
> I am looking forward to further compiler improvements, but I am wondering if the issue is exacerbated with the setup that Plots.jl uses (backends loaded on demand). If yes, I am not sure that solving this is a better use of time than, say, implementing a native Julia plot library from scratch.

It is not. Removing the conditional package loading in Plots does not help time-to-first-plot (we’ve tried), and implementing a native Julia plot library from scratch has been done - it’s called Makie and has a longer time-to-first-plot than Plots. This is a julia compiler thing, not a Plots thing.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 15, 2019, 2:30pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/58 "2019-04-15T14:30:55Z")

</div>

Thanks for the explanation. I am aware of Makie, my understanding is that it is a very powerful software package that does very fancy 3D, utilizes the GPU, etc. I was thinking more along the lines of something with the capabilities of GR, but in native Julia. Just emitting eg SVG and leaving the rest to external programs.

---

<div class="post-metadata">

**Author:** ![asinghvi17](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/asinghvi17/32/8272_2.png) [@asinghvi17](https://discourse.julialang.org/u/asinghvi17)\
**Post date:** [April 15, 2019, 3:40pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/59 "2019-04-15T15:40:43Z")

</div>

Maybe Gadfly? It doesn’t support 3d, but is written in pure Julia. [Home · Gadfly.jl](http://gadflyjl.org/stable/)

---

<div class="post-metadata">

**Author:** ![piever](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/piever/32/1815_2.png) [@piever](https://discourse.julialang.org/u/piever)\
**Post date:** [April 15, 2019, 5:39pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/60 "2019-04-15T17:39:02Z")

</div>

> [@Tamas\_Papp](#):
>
> I am aware of Makie, my understanding is that it is a very powerful software package that does very fancy 3D, utilizes the GPU, etc. I was thinking more along the lines of something with the capabilities of GR, but in native Julia. Just emitting eg SVG and leaving the rest to external programs.

It is not that simple though. I also thought the difficult part was the “rendering on the screen” part, but I’m no longer sure. I suspect part of the difficulty comes from having a pipeline that goes from potentially very different input to something that is “plottable”. Here for example I’m only loading AbstractPlotting, which is basically Makie without the OpenGL rendering and defaults to text rendering:

```julia
julia> using AbstractPlotting

julia> @time scatter(rand(10), rand(10))
 24.895688 seconds (61.68 M allocations: 3.087 GiB, 5.83% gc time)
Scene (960px, 540px):
events:
    window_area: GeometryTypes.HyperRectangle{2,Int64}([0, 0], [0, 0])
    window_dpi: 100.0
    window_open: false
    mousebuttons: Set(AbstractPlotting.Mouse.Button[])
    mouseposition: (0.0, 0.0)
    mousedrag: notpressed
    scroll: (0.0, 0.0)
    keyboardbuttons: Set(AbstractPlotting.Keyboard.Button[])
    unicode_input: Char[]
    dropped_files: String[]
    hasfocus: false
    entered_window: false
plots:
   *Axis2D{...}
   *Scatter{...}
subscenes:
   *scene(960px, 540px)

```

[Previous page](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956.md?page=2)

[Next page](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956.md?page=4)