On Mon, 4 Sept 2023 at 21:52, Roberto A. Foglietta <[email protected]> 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- _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
