For me the issue manifested as a 10 sec latency to format a Julia file using Format.jl
Solved via flags to disable JIT and brought it down to a couple of secs. Native binary would be much nicer.
Solved via flags to disable JIT and brought it down to a couple of secs. Native binary would be much nicer.
It wouldn't be so bad if the Julia developers acknowledged that this is a valid concern (that they are not dealing with it right now for whatever reasons) and that the ecosystem will not be considered complete until this fundamental problem is solved. But this is infuriatingly not the case. Instead, they tell you that you are "holding it wrong" and that this is not really a problem, that your usage is "niche", that the interpreter is alright as it is, and that the time to first plot is unlikely to ever go below a hundred milliseconds. I find it really depressing for the language itself is incredibly beautiful. My only hope is that an independent, fast and unix-friendly implementation of the language arises, thus freeing the reference implementation of the efficiency burden and allowing it to be simpler. Something like the lua/luajit split.
EDIT: also, sorry for the mis-characterization of Julia developers! I may have dealt until now with users and "fanboys" not real devs.
Here's a blog post that goes into some detail about the ongoing efforts to improve compiler latency: https://julialang.org/blog/2020/08/invalidations/
Now that you ask it, I realise it's been mostly through a few HN interactions! Every time I raised the issue in Julia posts over the last few years, I have been consistently ridiculed by purported Julia defenders. For example, in this very thread you can find a case of that.
I do get frustrated by characterizations of the interests of the Julia community that are very broad, and are also in evidence here. E.g. somewhere upthread one person claimed Julians are only interested in Jupyter Notebook workflows, which is a totally alien statement to me. Jupyter doesn't seem to have a very large mindshare as far as I can tell, I've never even tried it myself.
Static compilation and analysis comes up regularly on Discourse, but among the scientist part of the community, there is naturally less emphasis on this. Please don't extrapolate too far based on some isolated interactions.
How is that controversial or disappointing!? Why would anyone bother optimizing this? Nor is matlab/octave/python any faster.
`python3 -c "import matplotlib.pyplot as plt; plt.plot([1,2,3]);"` takes 600ms on my (powerful) workstation and that does not even include creating the plot window.
To be clear, I do believe there is much more work to be done to decrease latency in Julia, but your targets are ridiculous. And as a regular on their bugtracker and forum, the devs definitely acknowledge these issues and have many times said it is one of their main priorities.
By the way, if you want streaming live updated plots, this latency to first frame is not a problem. It is already straightforward to make such fast live plots in Julia (although it does not fit my personal taste for how to do it).
Only because you are not used to somewhat fast programs:
$ /usr/bin/time -v gnuplot -e 'set term png; plot sin(x)' > sin.png
...
User time (seconds): 0.02
System time (seconds): 0.00Julia is a terrible replacement for gnuplot and gnuplot is a terrible replacement for julia.
Maybe this example would make it clearer: why does your argument not apply to Python? Should we expect python libraries to come pre-cached so that the first time I load `sympy` I do not need to wait for tens of seconds to have .pyc files created. Or about matlab?
Again, I am all on board with the idea that julia needs lower latency and if you look at what their devs say, they also agree with that. But expecting Julia to be super low-latency (lower-latency than python/c/matlab) for your pet task is silly.
Another strategy: when a user installs Julia, they select “fast-loading” libraries. You’d be surprise how small changes in UI/UX make huge perceived differences in quality and performance. I bet “Julia can already do this” too, but nobody does it because it’s not idiomatic and it’s not recommended up front.
At the end of the day, people don’t complain about Python or MATLAB as much because they feel nicer. If it feels nicer because of some other reason than absolute time, then they’re doing something about UX that Julia is not, because everybody really does feel Julia is extremely sluggish to use.
There are better stats available (downloads), but I do not know of a good place to play with them publicly.
Don't most people already use a bit of PackageCompiler.jl in their workflows? Maybe it just need to be mentioned more in introduction videos, but it's literally one line of code to do this and I don't see how that isn't the solution already. Most users I know have been doing it for a few years now.
For reference, with Plots and DifferentialEquations the command is:
using PackageCompiler; create_sysimage([:Plots,:DifferentialEquations])
It's simple enough to add to every tutorial. I think the issue is that intro videos just need to be updated.
My suggestions: 1- please forget about the intro videos. Those are impossible to keep up-to-date, and are not a good reference resource. Sure, a future video should explain PackageCompiler, but that is not sufficient. 2- please update docs.julialang.org with all such guidelines. This is the likely the first place people look, so if there are important guidelines that everyone could benefit from, this is where they belong.
And to be clear, I do expect my second plot to be ready in tens of milliseconds.
eh..., it's open source. maybe they are just waiting for you to take care of it. just joking. i suspect there isn't ppl