search

tenox7 / ttyplot

a realtime plotting utility for terminal/console with data input from stdin
Apache License 2.0
956 stars 42 forks source link

On demand timeout (follow-up to #98) #144

Closed hartwork closed 7 months ago

hartwork commented 7 months ago

Follow-up to #98 in some sense

@edgar-bonet happy to adjust as needed or even close if this turns out to be the wrong way. Observed CPU load before and after was similar — jumping between 0.0%, 0.5% and 0.7%. Note the first commit. Looking forward to your review.

hartwork commented 7 months ago

I would avoid calling gettimeofday more than once within a single loop iteration: this requires extra logic to check whether tv_sec changed between the calls, and brings no tangible benefit.

Keep in mind that everything in the program is non-blocking except pslect. Even on a slow machine, the whole loop should complete within a millisecond or so. In this case, the code gets conceptually simpler if we rely on the concept of “current iteration time”. This means neglecting the time spent on computing, and assuming the current time is a constant within each iteration. Then, the right place to call gettimeofday is right when pselect returns.

And yes, this could mean the clock update gets up to one millisecond late, but I wouldn't care too much about that.

@edgar-bonet I'm pushing a new commit demoing that single-gettimeofday appraoch now, but it doesn't feel right knowing that drawing and input processing takes more than zero time while it could easily be accounted for, it feels wrong, there is not other way to put it.

hartwork commented 7 months ago

@edgar-bonet PS: I'm starting to think we should maybe go back to fixed 500ms, there was nothing truly wrong about it, and the complexity increase is missing payback in a way. How do you feel about that?

edgar-bonet commented 7 months ago

The “feels wrong” is a bit subjective. Maybe because I am used to thinking in terms of state machines and non-blocking event loops, the concept of “current iteration time” feels very natural to me. I do sometimes work with heavy simulation code and, in that context, the idea of neglecting simulation time would indeed feel very wrong. Different contexts, different feelings.

I'll give this whole thing a try.

hartwork commented 7 months ago

Closing in favor of #145…