search

martinvonz / jj

A Git-compatible VCS that is both simple and powerful
https://martinvonz.github.io/jj/
Apache License 2.0
8.27k stars 281 forks source link

Progress indiciator is redrawn too frequently #3506

Open dpc opened 5 months ago

dpc commented 5 months ago

Description

Steps to Reproduce the Problem

Use jj over some slower ssh connection. Run jj git fetch, watch how the redrawing progress bar slows down the whole ssh connection.

Expected Behavior

Limit the redraw frequency to 1/s, maybe slightly more.

Actual Behavior

Lag.

Specifications

khionu commented 5 months ago

This could probably be adaptive. There's likely a way we could measure, say, 200 redraws, and if they take longer than 1s, we could switch on a rate limit.

Addendum: As long as we're flushing each time, the buffer write should be synchronous after the draw, so that would give us the measure

dpc commented 5 months ago

It could, but I doubt anyone really needs FPS-game-like progress indication feedback. 10/s would probably both appear sufficiently smooth and not use too much badwidth no matter if used locally, over ssh, Tor, serial port, homing pigeon. It might struggle over smoke signals, I guess, due to really low bandwidth. But not exactly common use-case.

necauqua commented 5 months ago

Tor [..] homing pigeon

Idk man, some tor connections are incredibly slow. And IPoAC has decent effective bandwidth but the ping is horrendous

dpc commented 5 months ago

It seems to me that here the biggest issue is the amount of data piling up to be delivered to the client. It stack on top of the normal latency. Enabling ssh compression might help a lot (someone suggested in on Discord).

BTW. Personally 1/s is real-time-enough for me anyway.

khionu commented 5 months ago

I like very smooth CLI rendering like JJ does, myself, and would be saddened if it were gone entirely. It may not be necessary, but it's pleasant, and locally it's perfectly fine.