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

<div class="post-metadata">

**Author:** ![xiaodai](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xiaodai/32/15937_2.png) [@xiaodai](https://discourse.julialang.org/u/xiaodai)\
**Post date:** [August 19, 2019, 8:44am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/121 "2019-08-19T08:44:34Z")

</div>

Try Fezzik.jl

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [August 19, 2019, 12:19pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/122 "2019-08-19T12:19:38Z")

</div>

maybe my 2c on some of this …

1 I’m now long enough here to have seen several recommended plotting solutions come and go. The problem of time-to-first-plot never was really bypassed.  
2 The claims that GMT can do something other plotting packages cannot do (… try to do this in matlab …) are far-fetched. GMT has a sweet spot for projecting results onto maps which should not be surprising, because that’s GMT’s main job. The usability might be high here, but at the end-of-the-day julia needs a package/infrastructure that can plot into ANY given graphical context, may it be dedicated window, a tab of a browser, an OpenGL patterm etc. and afaics GMT has limitations (PS only?)  
3 It’s really ironic that someone upthread proposes to build a dedicated plotting library in C for julia to be fast when one of julias main claims is: Julia is solving the two-language problem …  
4 While a faster (or fast) code generation / compilation step is really appreciated, i think the way out (of problems like this for interactive REPL usage) is: code caching (between sessions) and similar compile-to-static. I got from Jeff’s lecture (“what is bad in julia”) the picture that julia will have more-and-improved-modularisation, so that a modules’ actions on data is fixed and not depending anymore on code called from/to other modules.

---

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

</div>

> [@davidanthoff](#):
>
> 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 🙂

I don’t think that’s true, and at the very least it would be nice to see your argumenting the basis of this negative statement. It’s slow loading (but otherwise really fast) because it’s written in Julia. Makie is even more so.

> [@Tamas\_Papp](#):
>
> 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.

This is just spreading false information, as Chris also remarked.

---

<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 19, 2019, 12:42pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/124 "2019-08-19T12:42:15Z")

</div>

> [@mkborregaard](#):
>
> This is just spreading false information, as Chris also remarked.

Apologies, my information was based on an incorrect understanding.

---

<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 19, 2019, 2:18pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/125 "2019-08-19T14:18:37Z")

</div>

> [@lobingera](#):
>
> 3 It’s really ironic that someone upthread proposes to build a dedicated plotting library in C for julia to be fast when one of julias main claims is: Julia is solving the two-language problem …

Sure… but the interface would still be in Julia. For example, ggplot or vega can be interfaced with Plots.jl. I don’t the “two-language” problem means all code needs to be written in Julia. We already use a few C libraries for other stuff (Linear Algebra? Matrix computations?)

---

<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 19, 2019, 2:28pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/126 "2019-08-19T14:28:00Z")

</div>

> [@affans](#):
>
> Sure… but the interface would still be in Julia. For example, ggplot or vega can be interfaced with Plots.jl. I don’t the “two-language” problem means all code needs to be written in Julia.

That still doesn’t handle the type-generic recursive argument pipeline, which is exactly what we want to have through something like Plots.jl but is causing the compilation issue. What makes us have automatic type handling and recipes is exactly what is causing over specialization. Interestingly, a blanket `@nospecialize` doesn’t help either, so it’s hard to see how to fix it. If you just want to call a C library and have no overhead, then you can already use GR.jl which is a good library for that, but of course it has to ignore types to do that.

> [@affans](#):
>
> We already use a few C libraries for other stuff (Linear Algebra? Matrix computations?)

Those are all specialized on `Array{Float64}`, `Array{Float32}`, and `Array{Complex...}`. Everything else has a generic Julia fallback or an error. We could do that with our plotting libraries (“error: every plot command has to end up at Array{Float64}s!”), but then of course plotting `Symmetric{Measurements{Complex}}` and stuff like that, which is right now handled automatically through the Plots.jl pipeline, would be a major pain.

---

<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 19, 2019, 2:31pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/127 "2019-08-19T14:31:47Z")

</div>

Fezzik.jl actually worked (as long as I didn’t do any plotting during the tracing period – causes some error during compilation since libGR cannot be found). Nice work!

---

<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:** [August 19, 2019, 3:28pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/128 "2019-08-19T15:28:08Z")

</div>

> [@affans](#):
>
> I don’t the “two-language” problem means all code needs to be written in Julia.

The two-language problem is when you need to use a second language in order to get acceptable performance. So, what would you call this?

It’s not a two-language problem for those who _call_ the library, necessarily, but it certainly is for those who _write_ it, or want to contribute to 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 19, 2019, 3:37pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/129 "2019-08-19T15:37:33Z")

</div>

> [@DNF](#):
>
> It’s not a two-language problem for those who _call_ the library, necessarily, but it certainly is for those who _write_ it, or want to contribute to it.

But ideally the boundary between the two groups should be easily permeable. (“Could have I feature X? Sure, make a PR.”)

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [August 19, 2019, 3:46pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/130 "2019-08-19T15:46:21Z")

</div>

So Julia is solving a problem, that ‘ideally’ doesn’t exist?

---

<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 19, 2019, 3:54pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/131 "2019-08-19T15:54:05Z")

</div>

I am sorry, I don’t understand what you are saying here.

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [August 19, 2019, 4:09pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/132 "2019-08-19T16:09:19Z")

</div>

I see.

---

<div class="post-metadata">

**Author:** ![mbaz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbaz/32/17295_2.png) [@mbaz](https://discourse.julialang.org/u/mbaz)\
**Post date:** [August 19, 2019, 6:16pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/133 "2019-08-19T18:16:57Z")

</div>

> [@Yifan\_Liu](#):
>
> I completely rely on Gaston and UnicodePlots for visualization.

For plotting using text in the REPL, you can also use Gaston’s `"dumb"` terminal. It’s not exactly equivalent to UnicodePlots.jl because it uses only ASCII, but for simpler plots it might be good enough.

---

<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 19, 2019, 7:46pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/134 "2019-08-19T19:46:36Z")

</div>

Do you have an example code for this “dumb” terminal plotting?

---

<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 19, 2019, 7:47pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/135 "2019-08-19T19:47:05Z")

</div>

Thanks @ChrisRackauckas , I understand the situation more clearly now. I don’t really have any more suggestions for a Julia-only implementation. I only spoke from the perspective of an end user of Julia. To me it’s irrelevant whether the plotting comes from an external (already compiled) library or a Julia implementation. Plotting is really the only thing that I usually switch to R/ggplot to (i.e. export simulation data from Julia, plot in R). So for me the two-language problem still remains for me.

I agree, at a higher level, a Julia plotting solution is likely the best way forward. It will also allow some of us to even submit PR where we may not be able to do that with a C (or other language) library.

---

<div class="post-metadata">

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

</div>

If we want a graphics package in Julia, then the question becomes what is the best open source graphics package, and how can we facilitate its translation into Julia. From the above, it sounds like the problem is overspecialization, though. So what is the solution to that?

---

<div class="post-metadata">

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

</div>

I love coding in julia and think it really does solve the two language problem for computing. For plotting, I still find myself firing up R and using ggplot. It’s just easier for me to get it right there and to do it fast. I don’t think it’s reasonable expecting julia to compete in the plotting space right now. That being said, I have high hopes for Makie and plotly in the longer run 😊

---

<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 19, 2019, 9:04pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/138 "2019-08-19T21:04:04Z")

</div>

It’s probably hard to get a straight answer from my previous rambling post. I personally think that in the absence of any large financially backed project to create a graphics system from the ground up that our best bet is Makie. OpenGL is widely used and even some of the more progressive efforts in computer graphics are motivated to incorporate it somehow.

---

<div class="post-metadata">

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

</div>

> [@Yifan\_Liu](#):
>
> Do you have an example code for this “dumb” terminal plotting?

```julia

julia> using Gaston
julia> set(terminal="dumb")
julia> t=0:0.05:1;
julia> plot(t,sin.(2π*t), size="50,20", title="A sine wave period")

                 A sine wave period               
                                                  
      +---------------------------------------+   
    1 |-+ ******* + + + +-|   
      | ** * |   
      | * * |   
  0.5 |-+ * * +-|   
      | * * |   
      | * * |   
    0 |-* * *-|   
      | * * |   
      | * * |   
 -0.5 |-+ * * +-|   
      | * ** |   
      | **** |   
   -1 |-+ + + + ***** +-|   
      +---------------------------------------+   
        0 0.2 0.4 0.6 0.8 1 

```

The “dumb” terminal is one of gnuplot’s default terminal drivers – see page 216 in the current [user manual](http://www.gnuplot.info/docs_5.2/Gnuplot_5.2.pdf).

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 20, 2019, 5:40pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/140 "2019-08-20T17:40:32Z")

</div>

> [@jeff.bezanson](#):
>
> In the meantime there are a couple tricks to try to work around latency issues:
> 
> 1. Try running with -O0 or -O1
> 2. Try running with --compile=min
> 3. Try applying this patch:

> [@jeff.bezanson](#):
>
> 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

Four others in this thread quoted `--compile=min`. I’ve seen -O3 been 42% slower (and if I recall the default -O2 about as slow) than -O0 on short scripts (using one thread) and over 60% slower with 4 threads, not sure that comparison is valid (see benchmark game thread), and ` --compile=min` way slower. -O0 may make most sense, at least for people on old machines as my decade old Core Duo laptop.

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

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