Thanks for making a pull request to jupyterlab!
To try out this branch on binder, follow this link:

Is 5s not too low with a risk of putting down the network and server with too many requests if many users are constantly typing?

Is 5s not too low with a risk of putting down the network and server with too many requests if many users are constantly typing?
you raised a valid point, what time would you suggest?

you raised a valid point, what time would you suggest?

Difficult to say without real benchmarks. TBH I find 1 minute a good tradeoff, but that is something that I would prefer seeing confirmed in real, as getting more feedbacks from the community.

you raised a valid point, what time would you suggest?

Difficult to say without real benchmarks. TBH I find 1 minute a good tradeoff, but that is something that I would prefer seeing confirmed in real, as getting more feedbacks from the community.

okay, let's see what the rest of the team suggest

@echarles A five-second timeout would produce, at the very most, 12 "save" command executions per minute per user. Realistically, because it only triggers 5 seconds after the most recent edit, we would see a lot fewer than this. What metrics would we need to collect to determine the impact of saving a file on server performance?

you raised a valid point, what time would you suggest?

Difficult to say without real benchmarks. TBH I find 1 minute a good tradeoff, but that is something that I would prefer seeing confirmed in real, as getting more feedbacks from the community.

@echarles did you take a look at @JasonWeill comment?

What metrics would we need to collect to determine the impact of saving a file on server performance?

I would take the biggest notebook you have ever work with, go to a place with a 2 bars wifi and see what it gives.

Working with notebooks on remote deployments I often see long delays for save operation (2-5 seconds) because my notebooks can include large visualisations and often are 20-50 MB in size (panel/holoviz dumping all their assets in the outputs are one culprit, SVG publication-quality visualisations are another). Even though I have ultra fast broadband at home the remote Jupyter Hubs often have limited capability to receive data (and upload is usually slower than download).

For example, in the UK the average upload speed is 18,4Mbps (2.3 MB/s). This means that a notebook with 50 MB takes 21s to upload for save (disregarding overheads). I think it is reasonable to change the save interval to once a minute or once every 30 seconds but I agree that once every 5 seconds is not a reasonable value for software which is often deployed on remote cloud or in HPC behind multiple hops of ssh.

I would however be open to having a different default for localhost users. This is if frontend sees that the URL is localhost it could default to 5s.

I would however be open to having a different default for localhost users. This is if frontend sees that the URL is localhost it could default to 5s.

Running the server on localhost will not always imply that the content is served from localhost, see #16744

Given the findings in #17017 I think this could be only considered if also making sure that notebooks that have not changed do not trigger auto-save.