takluyver
commented
7 years ago Besides the two network hops (websockets, zmq), we deserialise, reserialise, deserialise the message, and do a fair bit of manipulation in Python and Javascript. So I'm not sure whether there's one big cause of the slowness you see or dozens of small ones.
The code I'm sending to be executed is literally 'x=10+25**2'. When I run it 1000 times locally, error in the timing mechanism is still a similar order of magnitude aka estimating 10^-5 ms per run.
I think that's deceptive. Python doesn't do much optimisation, but one thing it does do is constant folding, so the bytecode for your code is equivalent to x=635.
# This roughly matches what you see
12│ %%timeit
│ x=10+25**2
│
12.8 ns ± 0.0428 ns per loop (mean ± std. dev. of 7 runs, 100000000 loops each)
# If we prevent it from doing constant folding, it's an order of magnitude slower
13│ a = 25
14│ %%timeit
│ x=10+a**2
│
220 ns ± 1.2 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
# Dynamic execution loses us another 2 orders of magnitude
16│ %%timeit
│ exec('x=10+a**2')
│
│
11.6 µs ± 44.1 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
# And IPython's machinery is another order of magnitude over that.
# This still doesn't include the serialisation and TCP steps.
18│ %%timeit
│ get_ipython().run_cell('x=10+a**2')
339 µs ± 2.37 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
Carreau
JMurph2015
rgbkrk
SylvainCorlay
Hi! This issue is being dropped here after discussion over on this thread: https://github.com/jupyter/kernel_gateway/issues/255
Intro
Basically the client interface to kernels is demonstrably adding a non-trivial amount of latency to every call made against a Jupyter notebook. Now one might ask "who cares about 8ms of latency?" and I would say anyone who would theoretically like to hit the Jupyter backend more than ~100 times a second. Reducing the latency to ~1ms should be achievable with the minimal overhead associated with ZMQ and the really minimal amount of post processing actually happening to any particular message.
What I've Seen So Far
This all means that I have ~7 ms (give or take 0.4ms for latency due to tcp and Websockets) that is unaccounted for. It would take a reasonably large amount of code to cause 7ms of delay (for example a simple prime sieve can find several thousand prime numbers in that sort of time).
Actual Question
If anyone has a good idea of what's taking 58x the time it takes me to dispatch calls to receive messages back, that would be awesome (it would be even more awesome if you could point me in the direction of changing that)