High CPU overhead when polling

[sayanarijit]

Describe the bug

Not sure if this is the real cause, or I'm doing something wrong, but any hint on how to optimize this polling overhead issue would be appreciated.

To Reproduce
Steps to reproduce the behavior:

1. git clone https://github.com/sayanarijit/xplr
2. cargo flamegraph --bin xplr
3. See the result.
4. Remove polling.
5. cargo flamegraph --bin xplr
6. Compare the result.

Expected behavior
The CPU should not to be too high, yet it gets pretty high. Increasing the timeout makes the app less responsive. Not sure how termion does it, but I haven't faced CPU issue with termion even with async read.

OS
Manjaro latest

Terminal/Console
Alacritty

[sigmaSd]

Hello,

You appear to be using poll with a small duration in a synchronous code, isn't cpu usage expected to be high in this case?

I think a more correct solution would be to either increase polling duration or use async (example https://github.com/crossterm-rs/crossterm/blob/master/examples/event-stream-tokio.rs)

[sigmaSd]

Also since you're reading events in a different threads what is the purpose of polling?, does simply blocking for read in that thread doesn't work?

Edit: I see you need that for the pausing feature, I guess async is the way to go

[sayanarijit]

The example uses the tokio runtime. I don't want to complicate things by introducing async runtime. Is there a way I can keep the asyncness isolated only to input reading?

[sayanarijit]

I think I can just not declare every function as async

[sigmaSd]

I think for async you will need to rewrite the codebase

I faced this before the trick that worked for me before is making the main thread controls when crossterm reads (std thread park after each read and the main thread unparks the crossterm thread when needed) but its definitly a hack

I guess we either need a solution to #397 or using an async codebase in these cases is the right answer

[sayanarijit]

Got it. Closing this.

[sayanarijit]

For future readers, another simpler approach is to increase the sleep time when the key is not being held (example). But of course, this needs to be tested to see how it impacts the responsiveness of the program.