[manwe150]

I helped work on getting that number from ~400ms to ~150ms maybe 18 month ago for the v1.0 release. FWIW, a big part of it was shedding a couple excess C libraries with bad load times (usually now lazy loading them when required instead). The next big jump will take more internal effort, but I don’t think there’s any serious showstopper. The bigger short-term interest though has been towards reducing the latency of loading external (user) code/libraries.

For an example of what I mean by the latter, python seems to be pretty fast initially, but then seems to take a huge hit from just trying to get numpy loaded.

    $ time python -c '0'
    real0m0.024s
    user0m0.016s
    sys0m0.008s

    $ time python -c 'import numpy'
    real0m0.165s
    user0m1.508s
    sys0m2.312s

    $ time ./julia -e 0
    real0m0.215s
    user0m0.240s
    sys0m0.144s

[owl57]

I believe you compared first (uncached) startup of Python against second startup of Julia:

    $ time python -c '0'
    python -c '0'  0,03s user 0,01s system 7% cpu 0,467 total
    $ time python -c '0'
    python -c '0'  0,03s user 0,00s system 98% cpu 0,030 total
    $ time python -c 'import numpy'
    python -c 'import numpy'  0,17s user 0,05s system 9% cpu 2,401 total
    $ time python -c 'import numpy'
    python -c 'import numpy'  0,11s user 0,01s system 99% cpu 0,118 total
    $ time julia -e 0
    julia -e 0  0,25s user 0,27s system 17% cpu 2,868 total
    $ time julia -e 0
    julia -e 0  0,09s user 0,05s system 92% cpu 0,155 total

The impact of actually calling something from numpy is also negligible in Python but not in Julia:

    $ time python -c 'import numpy; numpy.random.rand(10,10)'
    python -c 'import numpy; numpy.random.rand(10,10)'  0,10s user 0,01s system 99% cpu 0,116 total
    $ time julia -e 'rand(10,10)'
    julia -e 'rand(10,10)'  0,35s user 0,23s system 209% cpu 0,277 total
    $ time julia -e 'rand(10,10)'
    julia -e 'rand(10,10)'  0,36s user 0,22s system 209% cpu 0,278 total

[manwe150]

We got approximately the same numbers (your clock speed is likely to be much higher). User/system time is quasi-bogus, since it’s a high core count system (although still a bit concerning). I accounted for possible cache effect by running each a number of times and reporting the last. I’m not really trying to make an absolute time comparison here, just pointing out that if 100ms is unacceptable, numpy would just miss that bar too. Once you’re past the bar of “this needs to be kept running”, I don’t think a constant factor of 100ms vs 1s makes much difference in QoL, and now we’re just comparing apples and oranges. A constant factor gain on the rest of the time can make a huge difference on the rate of results per second. But I actually hope both will improve!

[owl57]

Ah. I was trained by zsh's time reporting to focus on the last figure and noticed that "real" is at the top in your comment only after posting mine. And then still left scratching my head looking at "user" and "system" times an order of magnitude higher than "real".

[elcritch]

Excellent! I was mainly going off the numbers given by another comment. Well ~150ms seems within useable CLI times for me. One note, I’d reckon to have a fair comparison to the Numpy timings the Julia example would need to use an array type to do something.