Why Julia is fast in interpreter but slow when dealing with files

General Usage Performance
1

I have this program written in a file:

using HTTP
using JSON

function pingserver()
    const addr = "http://localhost:4212/"
    const bdata = """{"type":"PING"}"""

    res = HTTP.post(addr, body=bdata)
    println(String(res.body))
end

pingserver()

CASE-1: I run it in terminal with _$ julia file.jl _ . It takes about 4-5 seconds to complete. It is very slow

CASE-2: I type this code inside Julia interpreter. it takes about 0.04 seconds to run.

Why running in terminal is 100 times slower than in interpreter. (Similar Python code takes less than a second to run in terminal).

1 Like
2

Julia’s REPL has a startup time. That startup time is longer than Python’s. Additionally, the first time code is run it has to compile. Packages don’t cache natively compiled code yet, though in the future they might. These two facts together means Julia has a longer startup time, but saying that it’s slow when “dealing with files” is misattributing what’s going on. Since it’s just startup time, it’s essentially constant. If you had some long computation, say 500 seconds, then it would take 504 seconds to do it from the file (since that’s just the opening up Julia time).

There’s been discussions for how future versions of Julia could address that. But since it doesn’t effect standard usage (how often are you starting Julia?) it hasn’t been a pre-1.0 priority.

4 Likes
3

Just out of curiosity: can you (or anyone else) explain why the REPL startup time is so slow? If startup was nearly instant then Julia could double as a brilliant language for writing batch files and other utility scripts.

(I tried to google this and search the forum, but all hits just referenced slow startup time of packages like Plots.jl.)

4

I would say startup / initial-compilation-time is slow because there is no way right now to really differ between “I want to run hardcore computations so optimizations are very important and worth doing” and “I want to run an interactive script, running everything interpreted is probably fine”.

On julia 0.7 you can try use julia --compile=no which will run the interpreter (disable any compilation). If you play around a bit in the REPL you can feel that stuff feel very “snappy”. However, any computational heavy code would be very slow. AFAIU the goal is to be able to more dynamically jump between running optimized code and the interpreter to get the best of both worlds.

Another reason for Julia being a bit slow to start is that it right now comes with quite a lot of functionality included. A BLAS system (that has to start a bunch of threads), a Sparse solver that has to be initialized and a few other libraries that all want to do their initialization. Moving to having this as optional “standard libraries” that can easily be disabled, would help.

5 Likes
5

Thanks! While you were typing I found this issue, but the only part that I really understood was BLAS initialization. I was going to ask for an ELI5 of the other points in the issue, but your post does that excellently.

As for startup time without the REPL, I tried timing julia helloworld.jl from the Windows command line. It completed in about 0.2 seconds (v0.6.2). This is fast enough for me, but probably still too slow for more serious command line tools.

6

The kind of answer I really wanted :slight_smile: … let it be 504 seconds, I will celebrate those 4 seconds for now I know more about Julia :sunglasses:

1 Like
7

@ChrisRackauckas ! :slight_smile: This is some kind of circular reasoning fallacy.

Of course that standard usage is as is if it is unusable in other areas… :wink:

8

No it’s not. That’s just silly. If logical fallacies can be expanded that far then even truths are fallacious. This can’t be circular since there was a start: there was a choice of what tools to work on at the start.

This is just choosing an audience and making a product for that audience, and then expanding later. Julia chose to aim for the scientific computing and data science space, and built a language with tooling that is great in that space since it’s constrained to a certain workflow. Other groups and workflows now want a taste of Julia. It’ll come, but it wasn’t the main focus from the start.

1 Like
9

Julia 0.7 startup was 2 times slower than 0.6 when I tested it last time. Do you check it too? How could you explain that?

10

Chris I don’t want to argue and I really respect your big work for Julia. :slight_smile:

This is much better argumentation! :slight_smile: I hope you see difference between this and your previous text.

And well I am member of this group… :confused:

I have to be probably more patient …

11

Well, instead of sitting around being patient, if you can, and there is some part of Julia that you feel can be improved, and you have some knowledge of how to improve it, start writing some code! :grinning:

It can be very addictive!

1 Like
12

0.7 isn’t final yet, and improving startup time will be one of the “polishing” steps. The released 0.7 should be better, and 1.0 hopefully better still.

6 Likes