pidof and pgrep are slower than a grep /proc/[1-9]*/comm

[Roberto A. Foglietta]

On Mon, 4 Sept 2023 at 21:52, Roberto A. Foglietta
<roberto.foglietta at gmail.com> wrote:
>
> Just few facts:
>
> - moving from local var=$(command) to local var; car=$(commad)
> - avoid to use pidof and pgrep but grep over /proc
> - source instead of calling a script
>
> The script time to be ready for the user interaction drops from 1.7s
> to 360ms.

I have managed to replicate the two systems behaviours:

SLOW 1.7s

- local var=$(command)
- pidof command1 command2 command3
- telnetd running on CPU0 only script as login handler
- busybox static with NOFORK option enabled

FASTEST 360ms

- local var; var=$(command)
- pgrep -E "command1|command2|command3" /proc/[1-9]*/comm
- telnetd running on CPU0 only sourcing a script as login handler
- taskset -pc 0-7 at the beginning of the script run by telnetd
- busybox static with NOFORK option enabled

OTHERS (from 450ms to 600ms)

- local var=$(command)
- pidof command1 command2 command3
- telnetd running on CPU0 only script as login handler
- busybox static with NOFORK option disabled

- local var=$(command)
- pidof command1 command2 command3
- telnetd running on CPU0 only script as login handler
- taskset -pc 0-7 at the beginning of the script run by telnetd
- busybox static with NOFORK option enabled

CONCLUSION

- busybox ash (standalone static) NOFORK running on a single CPU is a
bottleneck not a script interpreter.
- busybox ash (standalone static) NOFORK running on a multiple CPU is
faster than the forking version as expected.

I did not verify the code yet. However, I think that it is necessary
to introduce a test in the NOFORK code for which as long as busybox is
running on a single CPU, it forks otherwise follow the default policy
chosen at the building time.

I hope this helps, R-