I definitely agree that the current status is suboptimal. Lord only knows I've spent a lot of time thinking about ways to fix the slow global scope issue. Many but by no means all of these thoughts are in the issues Jacob linked to. If we figure out a solution that seems to be the right way to do it, it will be a really good day. Until then, it seems to me that the point of view that it's a bad thing to get a 32x speedup with very little effort or change is a lousy way to look at things. A lot of effort has been put into allowing that 32x speedup. Not coincidentally, 32x is about how much slower Python is for this kind of code; Matlab, R and Octave are slower.
I may have woken up on the wrong side of bed this morning (actually, I'm sure of that – I should probably stop answering emails), and I do apologize for being sarcastic or snarky about this. It's frustrating when so much work has been put into making it *possible* for a high-level dynamic language to run this fast and then the main commentary is about how it's not always that fast. It is possible to write slow code in any language – figuring out how to make your code fast is a learning process in every language except the ones where it can't be done. On Wed, Jul 23, 2014 at 10:18 AM, Kevin Squire <kevin.squ...@gmail.com> wrote: > On Wed, Jul 23, 2014 at 9:38 AM, Arnaud Amiel <aam...@gmail.com> wrote: > >> As suggested by a few of you, I put everything in a function and now it >> runs in 1/4 s, that is nearly 32 x improvement for 'no change' that is one >> of the aspects I don't like in julia. >> > > I've used Julia for a couple of years now, and am quite used to it, but I > very much agree with this sentiment. I recently introduced Julia to a > colleague, and he ran into exactly this issue--that timing direct commands > vs. the same commands in a function produce the same results with very > different timings. > > Having used and contributed to Julia for a while, I have a reasonably good > understanding of why this is the case and why it hasn't been fixed (and > might not be for a while). But I've often found it challenging to convey > this to others (especially those coming from languages where types are > often hidden, like Matlab). > > While I know this is on the radar of the main developers, a search didn't > yield an issue for better optimization of REPL inputs. Is there one that I > missed? Should there be? > > Cheers, > Kevin >
