# 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:** 1\
**Showing post:** 173

<div class="post-metadata">

**Author:** ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)\
**Post date:** [August 26, 2019, 6:25am UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/173 "2019-08-26T06:25:53Z")

</div>

> [@ChrisRackauckas](#):
>
> The solution is shown to more concretely be:
> 
> 1. Get rid of the KW nonsense
> 2. Concretize the argument handling earlier has to happen, otherwise you already take a 7 second hit
> 3. Concretization of the types should happen by the display function, since 13 seconds of it is type inference into the (hard coded and definitely not runtime loaded) gr\_display function. A large part of this is because the superlinear behavior of the compiler.
> 4. Get rid of Measures.jl. It has too much type information and causes issues. If anything, replace it with values and associated symbols, and hardcode branches instead of over dispatching. Units are just not a good idea for compile time… this would likely be helpful for Gadfly as well.
> 5. Throw a few declarations on the types in the structs that cannot be well inferred, but you know what they are by the time you dig a few functions down. This should only be a few pieces, not every argument that comes out of a KW.

These are very interesting observations. I started a question here:

> [@Does compile time depend on type stability](https://discourse.julialang.org/t/does-compile-time-depend-on-type-stability/6548):
>
> Hi, I have a larger Gtk.jl application that requires more than one minute to start up. If I press some buttons, the initial compile time is also quite high. However, if I run the application a second time everything is totally snappy. So runtime is absolutely ok. I was wondering if it actually helps when I try to make code type stable. So is type stable code faster to compile?

and

> [@Performance Issue with Gtk.jl](https://discourse.julialang.org/t/performance-issue-with-gtk-jl/6171):
>
> Hi, I have a performance issue that may be linked to Gtk.jl. My application needs 30 sec to start up the first time and profiling tells me that most of the time is spend in inference. The app is a little larger so that some dynamic typing (e.g. when using Dicts) cannot be avoided. The inference call is triggered from this line in Gtk.jl https://github.com/JuliaGraphics/Gtk.jl/blob/master/src/GLib/signals.jl#L11 it involves a cfunction so it may be linked to [Performance regression of Cuba.jl …](https://discourse.julialang.org/t/performance-regression-of-cuba-jl-on-julia-0-6/2424)

and

> [@Compiler Performance](https://discourse.julialang.org/t/compiler-performance/11307):
>
> Don’t know if this is the correct category but maybe: Since Julia 0.6 has been released I have seen major performance issues with Julia. After analyzing the issue a little bit I found out that it seems the compile performance that has regressed a lot. It seems that during the transition from 0.5 to 0.6 this has not been observed and I cannot really find deeper discussions on this subject. I now have some examples the regressed and I wonder if there is some “compiler benchmark suite” where the …

ad never got the answer that type inference itself is the problem. Would it be possible taking @ChrisRackauckas suggestions and putting them into the “performance tipps” section of the manual?

---

_[View the full topic](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956)._