Hacker News Reader

IMO, Python's performance can be a huge problem even when using it for purposes it's supposedly good for, like data processing. If you're doing NLP, you can use NLTK's built-in tokenisers and get pretty good performance. But if your situation calls for a slightly different tokeniser? You're gonna either write that in Python and absolutely tank your performance, or have a miserable time writing your own tokeniser as a C extension.

Or you can use PyPy of course, but that's a compatibility nightmare exactly when you're gluing together a bunch of C libraries with Python interfaces.

And in principle, JIT doesn't necessarily mean non-embeddable; LuaJIT is pretty good from an embedding perspective. Besides, I would assume they make JIT a build-time option so that people whose use case makes it problematic can use only the bytecode interpreter instead.

That said, your concerns about performance variability are warranted, and there are probably specific criticisms to be made about the choice of LLVM. LLVM is a gigantic dependency and I hope the performance wins of choosing LLVM rather than, say, crankshaft are worth it.

More glaring about the claimed performance gain is that they didn't mention what code they ran (as far as I could see). Was it a selected small piece of code or was it a big Django monolith? As I didn't see any mention of what code it was I'm going to assume the former, and that the latter will actually get worse performance. Because that is what typically happens when someone build a new JIT compiler. It takes a couple of iterations of optimizations for them to become useful on nontrivial code.

> This uses LLVM's JIT which is particularly slow and heavy (16MB added to the binary size) last time I tried to use it.

Incorrect, LLVM is only used in the compile time. See my other comments for details.

I looked into PR and you're correct. That's at least better than expectations.

> JITs are unbenchmarkable. No matter what you do, someone says you do it wrong.

Why does that matter?

Presumably if you care about Python performance, you have a real world scenario that you can benchmark. Just make a benchmark that is as representative as possible and check if the JIT helps. If it doesn't help, it surely can be disabled via an option.

> Why does it matter?

Because you need to have an idea of how many machines you need. And you need an idea of whether 'it will take as long as it takes' or if there's an issue in your code.

Sometimes Java decides to JIT using aes instructions. Sometimes it doesn't. Even if you run the same benchmark suite twice in a row it just does its own thing and gives wildly different results.

My learning was that one shouldn't depend on JIT performance and prefer using JNI libraries if you want consistency. Hence my comment being negative on JIT.

I don't know a lot about the Java JIT. But my guess is that the scenario you observed is the result of profile-guided optimisations done at runtime.

Hopefully this is a feature that can be disabled when you want deterministic behaviour. There's no reason to make it mandatory in a well-engineered VM.

JS V8, Java (any JVM), .NET use JITs.

If those aren't solid proving grounds for JITs, nothing is.

And nobody writes short lived commands in those because of startup time.

Do a quick test with the latest JVM.

Print Hello, world.

That's it. Time it.

Do the same with Python.

The difference is minuscule.

People don't build CLIs with them due to cultural reasons (fashion). Developers are creatures of fashion.

> Do a quick test with the latest JVM.

java: 031s python: 013s

it's 3x slower to start up… it means that any bash script with a loop calling a java command will run 3x slower.

3x slower isn't my definition of minuscule.

> java: 031s python: 013s

I'm confused, what kind of time measurement system is this? Are those 31 seconds versus 13 seconds? 0.31s vs 0.13s? If it's the first case, something is wrong with that machine, Hello World should not take that long. If it's the second, are we talking about 0.18s? See below.

> it's 3x slower to start up… it means that any bash script with a loop calling a java command will run 3x slower.

I don't know how you write your scripts, but in practice most scripts hang waiting for IO (especially network) or waiting for a specific command to process something...

> 3x slower isn't my definition of minuscule.

Nope, but based on what you've presented so far, unless I'm misunderstanding, it's my definition of "premature optimization".

double click selection issue. 0m0,031s vs 0m0,013s.

> I don't know how you write your scripts,

You know how… I put print hello world in them… that was the test you asked for?

> premature optimization

Not using something that has 3x startup time, for a short lived command is just "common sense".

I'm starting to think that the issue here is that you know java but don't know python or C, and you are unconsciously trying to get water to your own watermill.

I haven't written Java as my day to day for about 5 years. Instead I write... Python :-)

It's just that I recognize disingenuous comments.

Java is perfectly adequate as a language for writing command line tools. You're likely using one of them weekly and don't even know it.

Just don't write your Java CLIs using Spring or DI frameworks in general :-)

> You're likely using one of them weekly and don't even know it.

doubtful, since I don't have jre installed. I had to install it just to run that benchmark.

Modern Java tools bundle the runtime.

Printing hello world does not show the cost / benefit of a tracing jit that needs to be warmed up over thousands of iterations. And counter example: it takes maven 0.788s to realize I don't have a pom.xml in my PWD and fail a build. It takes meson 0.163s.

Maven versus Meson is purely about architecture, just look at Maven's design.

There is a reason I didn't say anything about that aspect of JITs that you mention, it's because it's not relevant to commands which are launched from shell scripts and then exit.

This is not the gotcha you think it is.

Rather those that don't know how to use the toolchains don't.

JIT caches, AOT have been an option for years.

And if you are really motivated, you can write stuff in C just like in Python.

You're naming things that need handling… which take time to be set up and so on.

I am naming things that need learning, pity that it is so big effort nowadays.

The things you personally already know aren't more worthy of learning just by virtue that you personally happen to have learnt them already.

You're just sticking with what you know, calling out the others for not wanting to learn.

Not a nice attitude from where I'm at.

We have gotten into a lazy learn attitude society.

> So why not make this AOT so I can add it to a docker build step and get all the benefit without the complications of tracing jits.

I've also thought this. If you're pre-baking your software, why not do this step as well?