Performance issue with `Timer`

[Byron]

This 'regression' appears a while ago in criner, and apparently went unnoticed when switching from tokio::time::Delay to async_io::Timer.

The picture above shows a criner process doing nothing, consuming 10 to 15% of CPU for displaying 4 progress bars which update once per second. The expensive part of this used to be the drawing itself, but now it appears to be dominated by the condvar in parking.

In smol 0.1.5 using smol::Timer, this looked like that:

All that shows up is the drawing of the TUI.

Having had a look myself I am absolutely puzzled as to why that is - the code looks very similar.

Any hint at how to solve this would be greatly appreciated.
Thank you

Meta

• 'utils.rs' on a criner branch that works as expected, without performance issues
  • It's noteworthy that criner didn't change in the relevant portions of the code responsible for the timer invocations see utils.rs.

• the version of 'utils.rs' that suffers from 'slow' timers

This should now be fixed in v0.1.7 - can you check?

[Byron]

Thanks a lot for your help! I think fixing this one will be important so that async-std doesn't get swamped with similar performance related tickets if they use the same timer implementation.

v0.1.7 It's a 'little' better, in that the CPU now sometimes drops under 10% to 8%, whereas usually it would be quite consistently at 11 to 12%.

A 12 second sample still yields a similar image as before (and for the uninitiated: TUI draw time should dominate the CPU, not the few 4 to 5 timers the application uses):

[Byron]

How to easily reproduce this�

git clone https://github.com/byron/prodash
cd prodash
cargo run --example dashboard --release  --features="tui-renderer tui-renderer-crossterm line-renderer line-renderer-crossterm ctrlc" 

The above program when profiled looks very much liker criner, in that the async-io code dominates the runtime. This one uses way more timers, so it's probably a great example to get fast (again).

Fixed in v0.1.8