On Sun, 10 Sept 2023 at 11:51, Roberto A. Foglietta <[email protected]> wrote: > > On Sun, 10 Sept 2023 at 11:41, Roberto A. Foglietta > <[email protected]> wrote: > > > > On Sat, 9 Sept 2023 at 17:14, Bastian Bittorf <[email protected]> wrote: > > > > > > I tried to replicate your findings, but my slow embedded OpenWRT > > > system (with musl libc) is so fast, that your tests always produce > > > 0 seconds execution time. > > > > Shows the test shell code and the results. > > > > redfishos:/rootfs # time date +%s%N > > 1689574011301750356 > > real 0m 0.00s > > > > for i in $(seq 1 100); do date +%s%N; done | time cat >/dev/null > > real 0m 0.45s > > > > As you can see here above, time or date without the nanosecond > > support cannot have the proper time resolution to see the difference > > on a single run. Did you consider this? > > https://unix.stackexchange.com/questions/167968/date-in-milliseconds-on-openwrt-on-arduino-yun > > This link might help you to understand and address what I am speaking > about (sub-seconds time resolution) >
Notice that the O(1, grep) vs O(N, pidof) is always present but to see a big difference N >> 1, like 8 or 10 for example. Using 2 for seeing the difference also works, but the difference can be more easily confused with some other source of lantencies. However, the O(1) vs O(N) is a fact that affects every system that relies on busybox pidof. Instead, to clog the system it is required two more conditions: 1. taskset -pc 0 $$ 2. busybox compiled with NOFORK If one of these conditions is missing, then the system works fine within the O(1) vs O(N) limit. To slow down the system even more, a third condition can be used: 3. local var=$(command); echo "$var" Again, also this condition does not affect the system in a sensitive way if one of the two previous conditions is missing. This explains because few people might have noticed something weird in their system before. Those who have a single core/thread CPU and tried NOFORK for improving the script's timing, probably decided to go back to the previous configuration without further investigation, accepting for explanation that their system is quite limited compared with the nowadays standards. Those who play with taskset, usually use it for a specific binary or a set of binaries which are supposed to deliver a real-time service and therefore receive a single CPU for their own only. Both of these cases are not common plus most of the people do not care about script speed execution because they accept that shell scripting is something slow by its own nature. I consolidated this opinion after having seen a lot of scripts in the real-world. In fact, most of them can be easily improved by many times in speed. The last one I reviewed, and modified just to adapt to my system got boosted by 7x times. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
