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

<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:** [September 1, 2019, 8:27pm UTC](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956/186 "2019-09-01T20:27:44Z")

</div>

> [@cce](#):
>
> the first time that a particular query is encountered it will cause a compilation. Since queries are constructed dynamically on the client side via a user interface, most queries will be unique. One work around is to have a parameterized query mechanism

Could you elaborate on this? Just can’t imagine such a scenario, where the backend has no idea even about the _structure_ of the potential queries so it would have to JIT-compile its reaction.

> [@dlfivefifty](#):
>
> There are four ways forward to help with this issue

I’d go for 1 (static comp.) + 4 (interpreter). When developing (prototyping), use the interpreter (JIT-compilation “in the background” would be awesome, but not mandatory). When runtime speed is crucial, enable the JIT for the final touches of development and optimisations. Then statically compile everything that’s known in advance, and leave dynamic one-off stuff at runtime to the interpreter (optionally with JIT-compilation in the background).

I think compilation can never reach the interactivity and the responsiveness for one-off calls of an interpreter.

---

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