Is the Eclipse IDE plugin "JuliaDT" still under development?

Zhong_Pan · May 10, 2017, 8:37pm

Just wonder with Juno (based on Atom) being included in JuliaPro as the default IDE, is the development on JuliaDT (based on Eclipse) still active? I hope it is.

Juno is very nice. However, I do feel JuliaDT has some advantages. For example, I found Juno runs code slower than a simple text terminal (for some Monte Carlo code Juno is 2x slower), even after the code has been run once first to remove JIT compilation impact. JuliaDT does not seem to have this problem. Also JuliaDT’s default multi-project view is nice. And by default JuliaDT runs the code in a fresh Julia console everytime, which makes more delay (due to JIT) but avoids all the messy warning messages of redefinition.

I feel that JuliaDT is a nice alternative to Juno, and I bet there are many programmers out there who would prefer a more established IDE like Eclipse.

Just my 2 cents.

avik · May 10, 2017, 10:39pm

Hi Zhong

I appreciate your preference for Eclipse, and agree with you that it would be good to have a many options when it comes to IDE choice. So we don’t intent to abandon the Eclipse IDE. However, you will appreciate that our resources are limited, and we need to prioritise where we put our effort. So we cannot promise when we will be able to put significant resources into it. If you, or anyone else, want to contribute to it in any way, we will be very grateful.

Regards

Avik

MikeInnes · May 11, 2017, 4:28pm

This is definitely not expected; please let us know if you have a test case for this.

Aside from that, Juno is pretty flexible and it should be possible to get the workflows you want. Totally fine to prefer Eclipse if that’s your thing, but if you have issues with Juno folks can probably help you get set up (for fix things that aren’t working properly).

Zhong_Pan · October 5, 2017, 5:43pm

I was using a pure text console to run Julia scripts. Today I came back to this issue. Julia has been updated to JuliaPro 0.6.0.1 (MKL), and I have installed all the updates in Juno.

For a relatively small piece of script, I noticed that Juno is still slower than the pure text console, but how big the difference is dramatically depends on the computer. For the following tests I always use the parameters “–depwarn=no -O0”, including in Juno by selecting the proper settings.I used ConEmu for the pure text console. Only one process is running for any Julia console.

(1) My laptop: Intel Core i7-6600U @ 2.6GHz, 8GB RAM, Windows 10 Enterprise 64-bit

Juno: first run anywhere between 10 to 22.3 sec; successive run 3.6 sec
ConEmu: first run 4.3 sec; successive run 2.3 sec.
Note: I found when the script is run for the first time in Juno, the processor usage shoots up to 80-100%. But when I run the script for the first time in ConEmu, the processor usage only reaches about 40%. The background processor usage is about 20%. There is always enough RAM left.

(2) My desktop: Intel Core i7-4770 @ 3.4GHz, 24GB RAM, Windows 10 Education 64-bit

Juno: first run 4.4 sec (processor usage up to 40%), successive run 2.0 sec.
ConEmu: first run 3.7 sec (processor usage up to 20%), successive run 1.9 sec.

So it appears to me that Juno requires a lot more processor power, and if the processor gets close to 100% utilization, the script run time in Juno can be very long.

pfitzseb · October 5, 2017, 6:03pm

Are you printing a lot in your script?

while true
  println("hi") 
end

e. g. will probably be orders of magnitude slower in Juno than in a terminal, but that’s not really relevant anyways, right?

If you’re not doing something like that, could you share a MWE that’s drastically slower in Juno?

Zhong_Pan · October 5, 2017, 8:04pm

Thanks for reply.

No it does not print a lot. The script only prints out 17 short lines of information. It reads in a 9MB CSV file and does a bunch of interpolations and simple array operations in loops. All codes are written in functions, some with input parameters and return values’ types annotated, others don’t. The only modules used are DataFrames and Polynomials.

Zhong_Pan · October 5, 2017, 9:02pm

To make the comparison as simple as possible, I recorded a video showing running a simple script for the firset time in a session in Juno vs. in a text only console.

See the video at: JunoVsConsole - YouTube

Script:

function main()
    println("Started!")
    for n = 1:10000
        x = rand(10000);
    end
    println("Done!");
end

@time main();

The section in Juno config.cson that governs Julia client is:

"julia-client":
    enableMenu: true
    enableToolBar: true
    juliaOptions:
      deprecationWarnings: false
      optimisationLevel: 0
    juliaPath: "C:\\JuliaPro\\Julia-0.6.0\\bin\\julia.exe"
    launchOnStartup: true
    useStandardLayout: true

You can see the parameters are the same as in the pure text console.

However, Juno seems to take much longer time (~15 sec when the blue bar is blinking slowly in the Juno console) to compile main() before running it, and the compilation seems to drive processor usage much higher.

This is what annoys me: to run scripts or commands in Juno for the first time it often takes over 10 seconds to “think”. Maybe it’s just because my ThinkPad Ultrabook is too weak?

Thanks!

jebej · October 5, 2017, 9:41pm

It might just be because julia isn’t actually running when you hit the “run script” button. Since julia needs to start, and the Juno packages need to load, it will take a bit time of time before the script starts running.

I know you have launchOnStartup set to true, but I don’t think that actually launches julia on startup… Try manually starting julia before running the script (e.g. enter 2+2 in the console).

Zhong_Pan · October 5, 2017, 11:43pm

Well I had no idea! Yes when I get through the waiting for running the first Julia command after Juno just starts, the execution for my script is much faster.

So Juno execution is not so slow as I had thought as long as Juno finished initialization. However, when I compare side to side running more complicated scripts again and again, still the pure text console is about 10-30% faster. I guess that’s just the overhead of Juno’s nice interface.

chakravala · October 6, 2017, 2:29am

Juno as an editor is very nice, but it is too slow. For me, anytime i switch away from the atom window and go back to it, the CPU runs at 100% for a few seconds before the atom window is usable again. Then it takes forever to load the Julia repl, I always keep multiple julia REPL’s in the terminal, but never in Juno. Typically, I need to restart the REPL often, since I am doing a lot of things that require restarts. Also, I often switch between my editor and web browser, and atom for some reason spins up the CPU to 100 percent just for switching back the window. Also, atom uses way too much memory compared to vim.

This is probably largely a problem that comes from the atom editor itself, since it is not so optimzed yet

I prefer the speed of VIM for editing, because I don’t need to wait a few seconds everytime I switch between windows. For a few months now I have been using the i3 tiling window manager, which basically gives me the Juno experience but for my whole operating system. I can just simply open lots of terminals with VIM and Julia running, tiled in the same way that Juno tiles the console and editor windows, but it works fast.

Using the Juno interface actually inspired me to fully switch to a tiling window manager, here’s an example:

Zhong_Pan · October 6, 2017, 8:02pm

chakravala That tiling window looks awsome and I bet the speed is lightning fast.

For my personal preference, I can never get myself proficient enough in VIM, and I still like an IDE that can do intellisense (auto-completion, function parameter prompt, documentation lookup, jump to definition/references, refractoring, and even debugging though I know Juno cannot do that properly today either - it’s a Julia feature to be desired not a Juno one).

I just discovered that Visual Studio Code, with the Julia add-in, seems to do a better job much faster. The basic interface is similar to Juno but all the funcitons work well and speedy. And though it’s Microsoft stuff, it’s actually cross platform.

I will try it out more and if anybody else is interested, here’s the download link.
Visual Studio Code: https://code.visualstudio.com/
Julia plugin (for now use the newest Beta as it fixed an important issue; in the future can just install from inside VS Code like installing plugins in Atom): Releases · julia-vscode/julia-vscode · GitHub (just download the vsix file, and in VS Code do: View, Extensions, …, Install from VSIX).

Here’s one screen shot:

There are still a couple things I’d like to see improved:

Ability to move the console window to the right, or just pop it out;
One button click to run the whole script (you can use a plugin called Code Runner - that’s the “run” button on the topright corner of the screenshot, but that will run the code as new everytime, so the compilation overhead is always there; I just use “include(“myscript.jl”)” in the terminal window myself;
And yes, debugging from within VS Code! This is what Julia has to provide first though.

Overall I am pretty happy with VS Code.

Yifan_Liu · December 11, 2018, 7:04pm

Is anyone using Julia in eclipse photon now? Some reviews say it is unusable. I have an office computer that only has eclipse and codelite.