I think at this point I could not recommend Atom with Juno for demoing Julia. The time delays are enormous. Would it be possible to figure out where this happens and fix it?
Perhaps this might help to illustrate my point:
The time delays are not due to Julia itself: here is ST3.
Couple questions: Do you have anything in your startup.jl? Is it this slow with Julia 1.2? There are some pretty big package load time regressions on 1.3-rc4 under some circumstances.
In comparison, this is what a fresh session looks like for me:
The ~8s displayed on the right is basically the time needed until Juno has loaded Atom.jl and established a connection. Everything after that is JIT compilation, which can look especially bad the first time you change something in a Julia editor, because we’re trying to generate the outline info (and the code that does that has a fairly high compilation cost).
So in summary:
If we fix compilation times for Julia code then this will get better.
If we improve package load times, this will get better.
If we’d do more lazy loading in Juno this would at least look better. We might also be able to whip up some precompile statements, but I’m not sure how big of a difference that will make.
Well, we’re loading a bunch of packages and opening a connection initially, so that is going to take longer than just starting Julia – there’s no way around that.
Then, when you switch to an editor, we figure out what module that file belongs to (if any) and statically parse all Julia code in that file and in files reachable from there to generate the outline.
If you type something, we’re getting autocompletions for you, complete with docs and inferred return types.
All of that is fast enough once compiled, but the compilation has to happen at some point. I’d imagine the whole experience to be much more satisfactory with everything compiled into the sysimg, but I haven’t tried that in a while.
You can also give the process cycler a go (enabled by default), which makes subsequent starts of Julia basically instant:
What you say makes a lot of sense. Don’t get me wrong, I love what Juno provides. It’s just that at this point it is not really usable for Julia demonstrations. I experienced that first hand giving a tutorial. During one of the waits, one of the students exclaimed out loud: “It would be faster to grab a calculator out of my bag!”
That’s a fair criticism, but can’t you just start a Julia process beforehand? That would also make for a much smoother experience when e.g. trying to plot something.
Hmmm, vscode has got breaking bugs and sublime is proprietary and does have a package the set guide is what feels like 20 pages long, definitely a barrier to entry? Don’t mind crowd funding something so we can add more resources to it?
I did. Is it too much to ask for simple instruction on waht to do with thatt? The readme is bare bones. Also, I think it would benefit from a simple step by step guide on how copy these configuration to a non-portable sublime installation e.g. Where do these configuration files go?
It would be a big service to the community if these can be packaged up as a sublime package so I can just package install it.
With the portable ST there is nothing else to do but the download the zip file, unzip, and run the editor.
For the regular ST, if you find an instruction which is incomplete or not understandable, please file an issue. I believe that I included instructions for all the configuration files, but I’m sure it could be improved.
This if what I see? So I have to go to full description on find out how to use this which is portable? I was wondering why not that simple description there. When I clicked on that link, I didn’t know what I was looking at.