search

purduesigbots / JINX

Interactive Graphical Debugger
7 stars 1 forks source link

JINX Falling Behind #4

Open ghost opened 7 years ago

ghost commented 7 years ago

In my experience with JINX, I have noticed that it does not parse data as fast as the Cortex can output it. And, because it tries to parse every line going to stdout, it noticeably lags behind the Cortex's output after some time.

I think JINX, as a temporary measure, should have a button that the user can press to discard all queued-for-parsing lines and continue parsing with the next line sent to stdout by the Cortex.

jwalk511 commented 7 years ago

Thanks for the input! JINX definitely uses more resources than it should for how slow it is now. Do you mind sharing what kind of rates you're outputting data at? I'd like to know what kind of target speeds to shoot for.

What I should be able to do immediately is read in the entire buffer at once, and pass it all as a single message. It'll clear the buffer, and the data won't be lost, just very unreadable.

ghost commented 7 years ago

Because I want to use JINX, even as it is currently, I slowed down my update rate to approximately every second (which JINX seems to handle fine for at least a few minutes, as few-minute sessions have been the extent of my testing thus far).

I think JINX definitely should support update rates as low as every 100ms. 20ms would be nice, as that is the default driver control loop delay in PROS, but I would not consider that speed necessary.

Edit: With that said, the web interface/server would also need to support faster updates, as the current fastest option seems to be every 1 second. And the web interface needs time units. But that's a separate matter...