Run times of julia much slower in juno than in terminal

davidzentlermunro · November 23, 2018, 2:41pm

I’m finding that when I run my code in juno, it takes significantly longer than when run on the terminal. I’m running an optimization routine which gets slower and slower as the evaluations increase (on juno, not terminal). is this to be expected?

pfitzseb · November 23, 2018, 3:33pm

No, this is definitely not expected.
Can you share the code you’re running and also how you’re running it in Juno and the REPL respectively?

ssfrr · November 23, 2018, 6:45pm

Also include your versions of the Julia and Atom packages. A while ago (maybe a year?) there was a similar issue that was caused by Atom’s high CPU usage rendering animations, but that should no longer be the case.

davidzentlermunro · November 26, 2018, 11:04am

Julia v1.0.1, and atom 1.32.2.

Here’s my rather messy code - appreciate this isn’t exactly a minimum working example though…!

https://github.com/davidzentlermunro/Minimum-Wage-Paper/blob/master/ModelCapSkillComp_fcalibSMM_frictions_imperfectsubs_beta_dist.jl

I run it on terminal via the “include” command and on atom by running the file (though even if I use" include" command within julia on atom I get the same thing - significantly slower run time.

pfitzseb · November 26, 2018, 11:53am

I think I can reproduce the performance difference in Juno vs a normal REPL. Can you try executing

using Logging; Logging.global_logger(Logging.NullLogger())

before executing the file (both in Juno and the REPL)?
Timings seem to be en par after that for me.

davidzentlermunro · November 27, 2018, 6:18pm

Yes thanks that works well. It’s be bugging me for a while - I should have asked sooner! Do I need to run it everytime I run any code with an optimizer?

Juan · November 28, 2018, 1:48am

Is this tip only applicable to Juno or also to other GUI frontends?

pfitzseb · November 29, 2018, 9:21am

Once per session is enough. I’m not sure what the root cause is, but I think this happens because of a performance problem in Base combined with Juno processing log events.

Depends on the internals of said GUI frontend If there’s nontrivial log event handling going on then it might help, yes. If in doubt, try it.

davidzentlermunro · February 8, 2019, 4:27pm

Note that I’ve just looked at this again: while using this tip does reduce the discrepancy I’m still finding that running code in terminal is a lot (4-5 times) faster than in atom.

pfitzseb · February 8, 2019, 5:08pm

Can you try profiling your code to figure out what’s taking more time in Juno? Is there some code for me to try and reproduce the slowdowns?

davidzentlermunro · February 15, 2019, 3:30pm

The bit that’s for sure taking a lot more time is the running of an optimizer, though when isolate this to try and construct a mwe the difference disappears. Here’s a link to the full code I’ve been using and encountering this problem in: https://github.com/davidzentlermunro/Capital-Skill-Complementarity

pfitzseb · February 15, 2019, 3:58pm

You have some data in directories not in that git repo (/Users/davidzentlermunro/OneDrive/KORV with frictions/Data/ etc).
Would also be interesting to know which part of the code is slow or if it is executing the whole file that’s slower.

davidzentlermunro · February 15, 2019, 5:13pm

All the data files are in the git repo, unless I’m overlooking something: which one do you seem to be missing? It’s the parts of the code that use blackboxoptim that seem to be causing the difficulty.

davidzentlermunro · February 18, 2019, 3:28pm

I’ve put simpler/less messy code in here: https://github.com/davidzentlermunro/Capital-Skill-Complementarity/blob/master/KORVestimationv_latest.jl

It turns out part of the problem was resolved by closing atom and reopening (even though on several occasions I had killed and restarted julia within atom) but I still get a speed discrepancy vs terminal.