Hacker News Reader

Comment by 0cf8612b2e1e | Hacker News Reader

Not that I expect this to have fantastic performance, but I think your benchmark is cheating. Locally hosted Jupyter is going to have significant overhead compared to a straight Python interpreter.

View on HN

On my machine parents test is;

   python command line 247µs 
   local  jupyter lab  274µs
          jupyter lite 4ms  (about 16 times slower than the other two)

Honestly considering how jupyter lite is working, I still feel this is pretty good.

I’m shocked the local instance is so tight with the interpreter. I assumed jupyter injected itself all over the place to allow halting loops and what have you.

I do not care about the performance of jupyer lite - that it runs at all is a miracle. That it is acceptable performance for doing demos/teaching from a browser is simply magic.

Jupyter is incredibly powerful. I think a lot of the surprise (which I also had) is when you come from compiled languages and see the huge difference between running a compiled machine code vs just some faux interpreter. Python doesn’t have that. Everything is an interpreter (in a very loose sense). Jupyter, ipython, the shell etc all typically work similarly. If you think the overhead of rendering a webpage should slow down Jupyter, that is not the case. The “kernel” running your code and what’s handling your interactivity with Jupyter are separate processes.

In Jupyter you choose Run Cell or Debug Cell. Debug Cell just uses sys.settrace like pdb does. Run Cell is straight python. Also, the example they gave pretty much calls into C straight away.

Why do you say that? I assume the timeit magic reduces a lot of overhead

Reply on news.ycombinator.com