Feature request: "compiling..." indicator


Probably one of the most characteristic properties of the Julia language is that compilation is done upon calls, which leads to the first run of everything to be slow. Sometimes very slow, like in many plotting packages. This can sometime lead to some frustratingly negative first impressions, and considerable puzzlement.

I think this perception could be greatly alleviated quite simply, by giving some visual hint that code is being compiled. After using the amazing ProgressMeter.jl I think having a “Compiling…” progress indicator of that style built into the REPL that would be triggered everytime something is being compiled would be really useful. Newcomers would understand what is going on during that first run. I don’t know enough about the compiler to know if an estimate of “progress percentage” can be computed. If not, a simple indicator without progress would still be very valuable, e.g. changing the julia> prompt into compiling>, or similar…

So, what do you think? Would you appreciate something like this? Is there any technical reason that would make this a problem?


Seems like it would get very spammy. It seems the best path forward would be for someone who is interested in this to provide a reference implementation so the results can be tried.


Yes, maybe a dynamic julia> prompt would be much nicer, with zero spam. Unfortunately I don’t have a clue how to hook into the different compiler stages, so I wouldn’t know where to start to implement this…


If the compiler knows how much effort is required then the REPL can show a progress bar when it’s expecterd to take more than few seconds (ideally a user customizable threshold). It would be best to show progress by package - a side benefit of knowing where to file an issue when something takes unexpectedly long.

The time to first plot probably triggers this :slight_smile:


It would be annoying if it was a progress bar, but I think it would be cool if julia> toggled to julia~ when a compilation happens. It doesnt have to be a tilde, but you get the idea, it would be a non-intrusive indicator that something is happening, and only during compilation.

Or the color of the julia prompt could toggle.


Yes, the prompt changing would be good. It would need to be in a way that its length of characters wouldn’t change. A progress bar or something else taking up space would be too much visual clutter. So +1 to @chakravala’s suggestion.


Ah, I’m now beginning to realise this proposal is not very viable. The option of changing the prompt to something different than compiling> or similar defeats the purpose, as the idea was to make it evident that something different than runtime was is taking place. Moreover there is a more serious problem, I think. Compilation does not simply happen before runtime, it can happen in between when a function gets called that has not been compiled yet. If anything gets printed in the REPL during runtime and then compilation starts again, we would need to know how to move the cursor back to the prompt, update it, and move it back to the end of the printed stuff. That’s probably overly complex and fragile. ProgressMeter.jl actually has this problem too, and cannot update the progress bar in-place when something gets printed as in this example:

julia> using ProgressMeter

julia> @showprogress for i in 1:3; @show i; sleep(1); end
i = 1
Progress:  33%|██████████████                           |  ETA: 0:00:02i = 2
Progress:  67%|███████████████████████████              |  ETA: 0:00:01i = 3
Progress: 100%|█████████████████████████████████████████| Time: 0:00:03


Nevertheless, an IDE could indicate compilation (eg in the modeline for Emacs, showing some graphical symbol in Juno, etc). It would be best to just provide hooks for this, so that the IDE could register functions to be called when compilation starts and ends, and represent this visually.


This is an interesting suggestion, since it eliminates often asked `why is my function taking so long’ type of questions that are due to precompilation and similar questions on why packages are slow. However, I agree with Kristoff, that this would probably be too noisy and frustrating to see. An implementation would indeed be interesting to test in practise how this works.