Jupyter Lab idle/busy status is changed for every mouse movement in Jupyter Lab, overwhelming the server

[kboone]

Version: jupyter-matplotlib 0.3.3 and JupyterLab version 1.1.4

In JupyterLab, whenever the mouse crosses over the canvas it sends a message to the server with the new coordinates every ~5 ms. For each message, the server responds with status update to busy message, a message to update the text, and a status update to idle message. It also updates the favicon, which seems to be causing more network requests (that are probably cached?) Needless to say, this completely overwhelms the server and leads to a lot of lag, even when running on a local machine.

There are two problems here: first, does it make sense to rate limit these update messages somehow?

Second, should there be some kind of timeout to prevent the kernel from flipping between busy/idle this fast? This might be something that needs to happen upstream in Jupyter Lab itself.

[kboone]

I submitted PR #146 which limits these requests to every 40 ms and significantly improves performance. This does not address the rapid busy/idle flipping though.

[thomasaarholt]

Why does the server need informing of the mouse position? Shouldn't responses like "current cursor coordinates" be handled on the client side? For what other purpose is this it needed? I guess there may be "hover" mechanisms in matplotlib that I'm not aware of, where the server needs updating?

[SylvainCorlay]

The entire rendering of figures is done in the backend. You can make mpl figures that react to mouse events.

[SylvainCorlay]

The kernel busy/idle status changing upon every mouse move is expected behavior.

[thomasaarholt]

Cool, that's fine then. I guess then one has to choose a compromise like @kboone does in #146. Are there standards for the expected update frequency? Is 40ms an "okay" refresh rate?

[SylvainCorlay]

I am closing the issue as the OP implemented some throttling of messages.

[SylvainCorlay]

Are there standards for the expected update frequency? Is 40ms an "okay" refresh rate?

We could make it configurable but a natural rate may be 60fps (~16ms) which is the rate of the browser.

[kboone]

I played with a few different values, and my browser can barely keep up at 40 ms with Jupyter Lab running locally. A lot of the overhead is flipping the kernel busy/idle status as three messages need to come back from the server for every message sent from the client. For a 16 ms delay, when continuously moving the mouse, I am close to maxing out the CPU on a modern machine (Intel i7-8565) and the server responses become significantly delayed. The requests also use ~4Mb/s both up and down. I think that the favicon changing has a fairly high overhead as the performance is somewhat better in Jupyter Notebook.

It doesn't really make sense to have Jupyter flip between busy/idle for every single request on the client side as this just causes the favicon and the busy/idle indicators to flicker. This adds a huge overhead to any fast operation (like this one). I suggest implementing throttling in the Jupyter server on the busy/idle status updates directly. For example, the server could still keep proper track of its state, but the client would only be taken out of busy mode if there has been no activity in the last 100 ms. This behavior would appear more natural: the busy indicator would be lit throughout the mouse movements rather than flickering continuously.

[SylvainCorlay]

I understand the reasoning although kernel busy/idle status messages are required by the protocol. I don't think updating the status indicator in the frontend is responsible for the CPU usage though. I suspect the way the message is handled by matplotlib in the backend would be more likely to use resources.

[kboone]

I played around with this a bit, with both local and remote servers, and it looks like both the frontend and backend have high CPU usage. I agree that any changes to the busy/idle status messages are beyond the scope of this repository and not something that can be easily changed.

It probably doesn't matter too much if the CPU is maxed out for the small amount of time that users are hovering over plots, so a 16 ms delay is probably fine for now. Let me know if you want a PR for that change.

[SylvainCorlay]

I left the 40ms. The 16ms was just me answering on whether there was a natural number.

Could as well be 42 :-)