# 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:** 6

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [August 16, 2019, 9:54pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/101 "2019-08-16T21:54:46Z")

</div>

> [@affans](#):
>
> Also how come packages like `ggplot` in R is so fast and powerful? is it because R is an interpreted language (which means the library for `ggplot` is already compiled)? Sorry for my dumb questions.

I think Plots.jl is just especially bad at load times, it is just littered with design decisions that make it load slow, as far as I can tell. A bit of a shame that the main plotting package for julia is such a collection of bad patterns in terms of load times 🙂

---

<div class="post-metadata">

**Author:** ![affans](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/affans/32/11911_2.png) [@affans](https://discourse.julialang.org/u/affans)\
**Post date:** [August 16, 2019, 9:57pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/102 "2019-08-16T21:57:07Z")

</div>

That would be the most perfect addition, atleast for me. Might it even be possible and feasible to interface it with `Plots`? For me this essentially solves the time-to-plot problem. I have no issues with using an external library.

Going even further, if `ggplot` is written in C, would it not be possible to use it directly from Julia? That way, we’d only have to maintain the wrapper, have access to a robust library, and solve the time-to-plot issue. It even has the added benefit that R users switching to Julia might have an easier and most comfortable transition.

---

<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:** [August 16, 2019, 10:06pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/103 "2019-08-16T22:06:22Z")

</div>

The problem with just using ggplot is that it’s actually not that versatile. When I stopped using R I read a comment from the developers that they were postponing adding interactive stuff to it until they could make time to just do that. So production will still need to be done somewhere if not in Julia. Also, multidimensional geometric support is critical to this which ggplot is not really known for.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [August 16, 2019, 10:06pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/104 "2019-08-16T22:06:41Z")

</div>

That’s precisely what happens when you do something like `using GR` and GR’s API directly instead of the unified Plots meta-package. Of course, this isn’t ggplot, but it’s the same idea — it uses an external binary to do most of the heavy lifting. GR can also be used through the Plots ecosystem, but by using it directly you can skip a lot of code. TTFP with GR is on the order of 5s, even if you need to recompile the GR.jl package.

The Plots ecosystem is powerful with its backend-agnostic API, but currently that power comes at a cost.

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [August 16, 2019, 10:14pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/105 "2019-08-16T22:14:21Z")

</div>

> [@Zach\_Christensen](#):
>
> The problem with just using ggplot is that it’s actually not that versatile. When I stopped using R I read a comment from the developers that they were postponing adding interactive stuff to it until they could make time to just do that.

I think at some point the plan had been ggplot2 would be replaced with ggvis (i.e. that might have been ggplot3), which is actually based on vega under the hood. I think that plan is dormant right now. But at least in general I think Hadley had planned to also utilize vega as the backend engine for the future of tidyverse plotting.

---

<div class="post-metadata">

**Author:** ![Steven\_Sagaert](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/steven_sagaert/32/29578_2.png) [@Steven\_Sagaert](https://discourse.julialang.org/u/Steven_Sagaert)\
**Post date:** [August 17, 2019, 7:57am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/106 "2019-08-17T07:57:56Z")

</div>

Yeah but those early prototypes were really limited and looked awful. Then plotly came along with a ggplot wrapper API and that was it.

---

<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:** [August 17, 2019, 11:27am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/107 "2019-08-17T11:27:03Z")

</div>

> [@affans](#):
>
> Can someone explain why the plotting library needs to be written in Julia?

There are two related questions here:

1. Having a fully native plotting library has a lot of advantages: better language integration, fast startup times, easier maintenance. Such a plotting library could be pretty fast with current Julia, but writing a nice plotting library is an enormous amount of work.

2. Plots.jl is not slow to start up because it is written in Julia, but because it contains a lot of conditionally loaded glue code.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 17, 2019, 11:30am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/108 "2019-08-17T11:30:53Z")

</div>

> [@Tamas\_Papp](#):
>
> 1. Plots.jl is not slow to start up because it is written in Julia, but because it contains a lot of conditionally loaded glue code.

It’s not really the conditionally loaded glue code but all of the function-barriers and inference failures in the pipeline code. GR isn’t even conditionally loaded since about 8 months ago?

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [August 17, 2019, 11:55am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/109 "2019-08-17T11:55:29Z")

</div>

> [@dlfivefifty](#):
>
> Existing libraries like GR are ok but still not Matlab quality. (PyPlot is pretty good but horrendously slow.) I think it’s just not realistic that there will ever be an open source C based plotting library, it’s too tedious to develop so only makes sense if a company is funding it.

GMT is not so feature rich as matplotlib but competes (and many times wins, specially in mapping) in quality with any other plotting library. Unfortunately the GMT.jl wrapper still has a TTFP only slightly less then 15 s. I which I understood more on the why of this so it could be cut by a factor of 2 or 3.

---

<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:** [August 17, 2019, 12:40pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/110 "2019-08-17T12:40:24Z")

</div>

I’m pretty limited when it comes to the details of programmatic graphics, so I apologize if this is completely off and feel free to correct me. But I do think this summarizes the problem space:

> [@Tamas\_Papp](#):
>
> 1. Having a fully native plotting library has a lot of advantages: better language integration, fast startup times, easier maintenance. Such a plotting library could be pretty fast with current Julia, but writing a nice plotting library is an enormous amount of work.
> 2. Plots.jl is not slow to start up because it is written in Julia, but because it contains a lot of conditionally loaded glue code.

I think the path forward on the second point will be solved as compilation latency continues to improve (which we’ve already seen) and the plotting library back end is really figured out. There’s a lot of smart people here so I have no doubt that it will get solved.

However, I’m worried about the first point because what it really comes down to is some sort of compromise. I’ve sat in on discussions like this for smaller projects and the conversation typically goes through these options.

1. Use a dedicated plotting library (matplotlib, ggplot, plotly, vega, etc.)
2. Use a bulky, well developed, and specialized graphics system that caters to data science (e.g, VTK)
3. Use a graphics library that’s not data science specific at all (e.g., OpenGL, Unity, etc.)

The first one is what we currently have in a couple forms. We obviously want it to do more faster but there are people that are actively making that happen. If we stop here then we are pretty limited in being able to do high performance 3D graphs (I know there are implementations of these but I’ve always gotten a lot of lag using these).

The second one is what R and Python did when they got the first one figured out. It works but is ultimately a highly segmented ecosystem that doesn’t communicate together and requires large complicated libraries (also, you’ve ever had to download VTK and ITK before on Windows your soul will die a little).

The third option is the best if you can get to a final product. There are major commercial efforts to contribute to graphics libraries and the burden of installing and maintaining a large graphics system on multiple operating systems is typically already handled by other parties. However, people that actually know what they are doing have to write a lot of well thought out glue code to make these work. This is what Makie is doing and seems like an ambitious but exciting effort.

In a perfect world some company trying to break into the market (like Google’s Stadia efforts) would pour tons of funding into a pure Julia graphics system. But I wouldn’t hold out for that.

---

<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:** [August 17, 2019, 12:56pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/111 "2019-08-17T12:56:43Z")

</div>

Yes I think that summarises it perfectly. I imagine the situation for people looking for 2D data visualisation is not too bad apart from time to first plot, in that there are several full featured plotting packages. But for 3D scientific computing plotting the situation is miles behind Matlab (or Mathematica). I know of a lot of potential Julia users that are sticking to Matlab for this reason.

A good example is say plotting a live movie of a heat map on a sphere. This is easy and pretty fast in Matlab. I don’t think any package apart from Makie can do it in Julia. But Makies still not as easy as Matlab, with the time to first plot being horrendous.

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [August 17, 2019, 2:43pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/112 "2019-08-17T14:43:26Z")

</div>

Tell your friends to do this with Matlab 😄

[https://docs.generic-mapping-tools.org/dev/gallery/anim07.html#anim-07](https://docs.generic-mapping-tools.org/dev/gallery/anim07.html#anim-07)

[https://docs.generic-mapping-tools.org/dev/gallery/anim08.html#anim-08](https://docs.generic-mapping-tools.org/dev/gallery/anim08.html#anim-08)

---

<div class="post-metadata">

**Author:** ![RoyiAvital](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/royiavital/32/571_2.png) [@RoyiAvital](https://discourse.julialang.org/u/RoyiAvital)\
**Post date:** [August 17, 2019, 5:58pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/113 "2019-08-17T17:58:44Z")

</div>

> [@joa-quim](#):
>
> Tell your friends to do this with Matlab 😄
> 
> [https://docs.generic-mapping-tools.org/dev/gallery/anim07.html#anim-07](https://docs.generic-mapping-tools.org/dev/gallery/anim07.html#anim-07)
> 
> [https://docs.generic-mapping-tools.org/dev/gallery/anim08.html#anim-08](https://docs.generic-mapping-tools.org/dev/gallery/anim08.html#anim-08)

Just use the [MATLAB Wrapper](https://docs.generic-mapping-tools.org/latest/ml_wrapper.html)?

---

<div class="post-metadata">

**Author:** ![Yifan\_Liu](https://avatars.discourse-cdn.com/v4/letter/y/4da419/32.png) [@Yifan\_Liu](https://discourse.julialang.org/u/Yifan_Liu)\
**Post date:** [August 17, 2019, 6:24pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/114 "2019-08-17T18:24:37Z")

</div>

If you want to know what your data looks like, just use UnicodePlots. If you need to save a plot, use Gaston.

I completely rely on Gaston and UnicodePlots for visualization. They work very well.

---

<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:** [August 17, 2019, 7:41pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/115 "2019-08-17T19:41:24Z")

</div>

This question finally has a solution, just use MATLAB 🤣

EDIT: Wait, that’s a wrapper for using GMT inside MATLAB…

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [August 17, 2019, 8:03pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/116 "2019-08-17T20:03:58Z")

</div>

Yes, there is a wrapper to use GMT inside Matlab but there is also one to use it from Julia. That’s the [GMT.jl](https://github.com/GenericMappingTools/GMT.jl) that I referred above.

---

<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:** [August 17, 2019, 8:16pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/117 "2019-08-17T20:16:30Z")

</div>

I thought the suggestion was a wrapper to use Matlab inside Julia, which might actually be reasonable. The “tell your friends to do _this_ in Matlab” statement misses the point: they don’t want to do what Matlab can’t do, they want to do what Matlab can do, as easily as it does it, in Julia. Pointing to what appears to be a command line based plotting package specifically for maps with confusing docs is not going to cut it.

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [August 17, 2019, 8:30pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/118 "2019-08-17T20:30:01Z")

</div>

> [@dlfivefifty](#):
>
> A good example is say plotting a live movie of a heat map on a sphere. This is easy and pretty fast in Matlab. I don’t think any package apart from Makie can do it in Julia

Well, my answer was mostly to this comment. Yes it can be done with GMT from Julia. But for this particular module that uses internally many self generated scripts it’s going to be tough not to use the the GMT’s terse syntax.

---

<div class="post-metadata">

**Author:** ![oschulz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oschulz/32/2998_2.png) [@oschulz](https://discourse.julialang.org/u/oschulz)\
**Post date:** [August 17, 2019, 8:55pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/119 "2019-08-17T20:55:19Z")

</div>

> As far as I can tell, the _only_ strategy that will provide the experience you describe of interpreter-like latency for first-time users is using an interpreter and doing compilation in the background.

I would argue that caching of binary code (if feasible) would also provide that kind of experience. Like most of us, I’m used to first-time Julia user’s complaining that Python get’s them the first plot faster - but I think they really mean “in a new session”. I think most users would be fine with things taking a long time for the very first plot (i.e. in the first session). Particularly the kind of user that will not do heavy package development, so cached code could stay valid for quite a while (a few days between waiting a long time for a first plot should make most people happy).

---

<div class="post-metadata">

**Author:** ![asprionj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/asprionj/32/6856_2.png) [@asprionj](https://discourse.julialang.org/u/asprionj)\
**Post date:** [August 18, 2019, 9:16pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/120 "2019-08-18T21:16:03Z")

</div>

> [@kevbonham](#):
>
> developing a command line script is a bit annoying, since every invokation may take 10-15 sec to even get started

I do have such a use case right now. It’s about running some Julia script (simulation etc.) from an external test framework. The simplest thing to automate such stuff is to just have one command such as `julia my_script.jl`. Precompiling packages into the system image helped a lot in reducing startup and JIT overhead. But when trying to also compile the function calls used in these scripts into the image (using `compile_incremental`) always fails, and resolving one error just leads to the next one etc. If this would be working, one could use all “cases” for snooping once, compile everything into the sysimage, then run repeated calls to those cases with _zero_ startup+JIT overhead.

One idea here was to just have a Julia session (or multiple sessions?) running and somehow call into them to trigger stuff (the simulations, i.e. test cases). What would be a good way of doing this? (I know, quite off topic, but where to put it? Usage \> Performance?)

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

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