Very high CPU consumption

[spasche]

Hi,
hwatch is a great tool. However, I noticed that its CPU consumption is very high.
A simple hwatch -n 10 date consumes about 20% CPU on an i7-5557U CPU (tested with version 0.3.3 on Ubuntu 22.04 with kernel 5.15.0-27-generic).
Here's a strace output when I let it run for about 20 seconds:

strace -C hwatch -n 10 date
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.98    1.295830      323957         4           futex
  0.01    0.000128          42         3           munmap
  0.00    0.000036           6         6           open
  0.00    0.000024          24         1           madvise
  0.00    0.000015           1         9           write
  0.00    0.000014           2         6           fcntl
  0.00    0.000013           2         6           close
  0.00    0.000009           0        11           ioctl
  0.00    0.000000           0         1           poll
  0.00    0.000000           0         6           mmap
  0.00    0.000000           0         3           mprotect
  0.00    0.000000           0       125           brk
  0.00    0.000000           0         5           rt_sigaction
  0.00    0.000000           0         8           rt_sigprocmask
  0.00    0.000000           0         2           clone
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         3           sigaltstack
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0         1           set_tid_address
  0.00    0.000000           0         1           getrandom
------ ----------- ----------- --------- --------- ----------------
100.00    1.296069        6384       203           total

[blacknon]

Thank you for information!
I have confirmed this issue on Linux (debian 10).

I usually developed it on a Mac, but CPU usage didn't seem to be a problem here. Therefore, it seems that this event could not be confirmed.

[blacknon]

From the situation, it is possible that the cause is Mutex lock, used in CommandResult.
Considering how to deal with it.

There is a high possibility of recv_timeout of Receiver.

hwatch/src/app.rs

Line 182 in 3181b94

match self.rx.recv_timeout(Duration::from_secs(60)) {

futex(0x55555658b068, FUTEX_WAIT_PRIVATE, 4294967295, {tv_sec=59, tv_nsec=999998534}) = 0
open("/dev/tty", O_RDONLY|O_CLOEXEC)    = 9
fcntl(9, F_SETFD, FD_CLOEXEC)           = 0
ioctl(9, TIOCGWINSZ, {ws_row=39, ws_col=143, ws_xpixel=1144, ws_ypixel=312}) = 0
close(9)                                = 0
write(1, "\33[1;138H\33[38;5;6m4\33[1;143H5\33[3;3"..., 268) = 268
futex(0x55555658b068, FUTEX_WAIT_PRIVATE, 4294967295, {tv_sec=59, tv_nsec=999998024}) = 0
open("/dev/tty", O_RDONLY|O_CLOEXEC)    = 9
fcntl(9, F_SETFD, FD_CLOEXEC)           = 0
ioctl(9, TIOCGWINSZ, {ws_row=39, ws_col=143, ws_xpixel=1144, ws_ypixel=312}) = 0
close(9)                                = 0
write(1, "\33[1;135H\33[38;5;6m20\33[1;138H0\33[1;"..., 318) = 318
futex(0x55555658b068, FUTEX_WAIT_PRIVATE, 4294967295, {tv_sec=59, tv_nsec=999998211}

[spasche]

Thanks, I can confirm that CPU usage with 0.3.4 is now negligible