6 ms·

> What do you mean by TTFP? Time To First Plot. It was a meme back then that you needed to wait several minutes to draw just a simple line plot after starting

> What do you mean by TTFP? Time To First Plot. It was a meme back then that you needed to wait several minutes to draw just a simple line plot after starting up a Julia REPL/notebook because of compilation times (whereas in Python you're done in seconds with matplotlib.) Seems this has been reduced in Julia 1.9 with automatic pre-compilation of packages, but plotting still isn't "instant" as you would expect in scripting languages like Python.

sgt101 3y ago
It seems instant to me - the package compile on first invocation is rather like installing with pip or conda, and then after that I see the plot in about 1/20th second.
- leephillips 3y ago
  The REPL starts up instantly and the first plot is < 1s. People seem to be repeating complaints (valid at the time) that they overheard from three years ago.
  - jampekka 3y ago
    This is not the complaint. The complaint is that running "$ julia someplotting.jl" takes a long time (actually with 1.9.0 it's reasonable at < 3s, but adding other libraries makes it easily tens of seconds or even minutes). Everybody doesn't use the REPL. In my, I think quite well founded, opinion nobody should use the REPL for more than one or two lines.
    - sanderjd 3y ago
      For what it's worth, as someone who shares a sense that "scientific" programmers have a tendency to over-use notebooks and REPLs, I find your perspective on it to be too extreme in the other direction! It's perfectly possible to incorporate interactive tools into a good software development process.
      - jampekka 3y ago
        I don't mean that running in Bash should be THE workflow. But I think it should be supported and it's used widely and lack of support for it is a major reason why Julia is not taking off. I'm not proposing taking REPL/stateful-notebook away from those who want to use it (although I'll advise them against it if asked). I don't find my plt.plot(x,y); plt.show() in a script ideal either. Something like Pluto.jl (given it's easy to modularize and preferably can be run without a notebook environment) is most likely better for a typical data analysis workflow (and will likely lead to more reproducible results and better tracking of result provenance).
        sanderjd 3y ago
        But there isn't "lack of support" for running cli scripts, there's just a few seconds of startup time (or less than that; it depends a lot on what dependencies the project has, in my experience). Like, I don't want to diminish that this amount of latency matters, but I just feel like you're being hyperbolic. I've used tools with more startup time for most of my career - the jvm, ruby when running any non-trivial rails app, essentially every ahead-of-time compiled language, etc. - it's not a good thing, and all those tools have invested massively in improving their startup times because of that, but I just really don't see how it can be considered a deal-breaker... (And for what it's worth, most non-trivial python codebases I work with also spend a ton of time starting up, though this can be fixed with investment into it.)
        jampekka 3y ago
        Especially for data analysis the latency is crucial. I run the code practically on every time I change a line. It's not that different from how people run REPLs, but I just keep the lines in files that I run. Would people be just fine if each REPL line would have tens of seconds of latency overhead? For different cases, e.g. application development, the latency is not that critical. Although I find it quite insane that we accept so slow code iterations this day and age.
        sanderjd 3y ago
jampekka 3y ago
For many complaints TTFP is not about REPL or notebook. It's about how long it takes for a new Julia process to do the plot. TTFP is (close to) solved. 1.9.0 TTFP is under 3 seconds for me, which I find about acceptable for script-type workflow. However, time-to-first-DynamicalSystems is still around 10 seconds, which is not.
- ChrisRackauckas 3y ago
  Loading new Julia processes takes long because the standard library is rather large. One big part of v1.10 has been the excision of more standard libraries out of the the core image. This required some of the v1.9 and v1.10 improvements because things like `using Pkg` was practically instant as a result of Pkg being in the system image, and thus moving these out of the base system image without a major regression required all of the package binaries infrastructure. The ecosystem is now getting ready for this change with recently all packages now requiring the versioning of standard libraries, standard libraries are now versioned independent of Julia and can do their own releases, so they are very close to be standalone. I'm not sure the progress with this in v1.11 but I think the intention was fto make it so that things like Pkg do not load with the start of Julia. The big elephant in the room there is then for BLAS to not load until `using LinearAlgebra`. The majority of the startup time is just spinning up BLAS threads the last time I checked, and with all of these other changes in place we should be ready to test this removal.
  - sanderjd 3y ago
    Useful info!! This is sort of a lazy-web thing, but do you know where this work is being organized or how one might start contributing to it?
    - sundarurfriend 3y ago
      I don't think there's a central organizing place, the work is happening across several Github issues and PRs. There's the Internals subforum [1] on Discourse if you have questions or need guidance, and there's a #internals channel on the Slack too. [1] https://discourse.julialang.org/c/dev/5 https://discourse.julialang.org/c/dev/5

sgt101 3y ago

It seems instant to me - the package compile on first invocation is rather like installing with pip or conda, and then after that I see the plot in about 1/20th second.

leephillips 3y ago
The REPL starts up instantly and the first plot is < 1s. People seem to be repeating complaints (valid at the time) that they overheard from three years ago.
- jampekka 3y ago
  This is not the complaint. The complaint is that running "$ julia someplotting.jl" takes a long time (actually with 1.9.0 it's reasonable at < 3s, but adding other libraries makes it easily tens of seconds or even minutes). Everybody doesn't use the REPL. In my, I think quite well founded, opinion nobody should use the REPL for more than one or two lines.
  - sanderjd 3y ago
    For what it's worth, as someone who shares a sense that "scientific" programmers have a tendency to over-use notebooks and REPLs, I find your perspective on it to be too extreme in the other direction! It's perfectly possible to incorporate interactive tools into a good software development process.
    - jampekka 3y ago
      I don't mean that running in Bash should be THE workflow. But I think it should be supported and it's used widely and lack of support for it is a major reason why Julia is not taking off. I'm not proposing taking REPL/stateful-notebook away from those who want to use it (although I'll advise them against it if asked). I don't find my plt.plot(x,y); plt.show() in a script ideal either. Something like Pluto.jl (given it's easy to modularize and preferably can be run without a notebook environment) is most likely better for a typical data analysis workflow (and will likely lead to more reproducible results and better tracking of result provenance).
      - sanderjd 3y ago
        But there isn't "lack of support" for running cli scripts, there's just a few seconds of startup time (or less than that; it depends a lot on what dependencies the project has, in my experience). Like, I don't want to diminish that this amount of latency matters, but I just feel like you're being hyperbolic. I've used tools with more startup time for most of my career - the jvm, ruby when running any non-trivial rails app, essentially every ahead-of-time compiled language, etc. - it's not a good thing, and all those tools have invested massively in improving their startup times because of that, but I just really don't see how it can be considered a deal-breaker... (And for what it's worth, most non-trivial python codebases I work with also spend a ton of time starting up, though this can be fixed with investment into it.)
        jampekka 3y ago
        Especially for data analysis the latency is crucial. I run the code practically on every time I change a line. It's not that different from how people run REPLs, but I just keep the lines in files that I run. Would people be just fine if each REPL line would have tens of seconds of latency overhead? For different cases, e.g. application development, the latency is not that critical. Although I find it quite insane that we accept so slow code iterations this day and age.
        sanderjd 3y ago

jampekka 3y ago

For many complaints TTFP is not about REPL or notebook. It's about how long it takes for a new Julia process to do the plot. TTFP is (close to) solved. 1.9.0 TTFP is under 3 seconds for me, which I find about acceptable for script-type workflow. However, time-to-first-DynamicalSystems is still around 10 seconds, which is not.

ChrisRackauckas 3y ago
Loading new Julia processes takes long because the standard library is rather large. One big part of v1.10 has been the excision of more standard libraries out of the the core image. This required some of the v1.9 and v1.10 improvements because things like `using Pkg` was practically instant as a result of Pkg being in the system image, and thus moving these out of the base system image without a major regression required all of the package binaries infrastructure. The ecosystem is now getting ready for this change with recently all packages now requiring the versioning of standard libraries, standard libraries are now versioned independent of Julia and can do their own releases, so they are very close to be standalone. I'm not sure the progress with this in v1.11 but I think the intention was fto make it so that things like Pkg do not load with the start of Julia. The big elephant in the room there is then for BLAS to not load until `using LinearAlgebra`. The majority of the startup time is just spinning up BLAS threads the last time I checked, and with all of these other changes in place we should be ready to test this removal.
- sanderjd 3y ago
  Useful info!! This is sort of a lazy-web thing, but do you know where this work is being organized or how one might start contributing to it?
  - sundarurfriend 3y ago
    I don't think there's a central organizing place, the work is happening across several Github issues and PRs. There's the Internals subforum [1] on Discourse if you have questions or need guidance, and there's a #internals channel on the Slack too. [1] https://discourse.julialang.org/c/dev/5 https://discourse.julialang.org/c/dev/5