Performance concerns when heavily used in scripts ?

Posted Mar 18, 2025 23:36 UTC (Tue) by PeeWee (guest, #175777)
In reply to: Performance concerns when heavily used in scripts ? by willy
Parent article: Oxidizing Ubuntu: adopting Rust utilities by default

But all the other coreutils, findutils, what have you, play a big part in the performance of the shell script, since the shell is just the glue, basically. And when true is already rather slow what else is in store? Don't get too hung up on true is all I am saying. I'm sure, the above examples were chosen because it is such a trivial executable and thus lends itself to measure the overhead of running uu-coreutils.

Performance concerns when heavily used in scripts ?

Posted Mar 19, 2025 5:06 UTC (Wed) by joib (subscriber, #8541) [Link] (2 responses)

> And when true is already rather slow what else is in store?

I don't think you can extrapolate from the startup overhead to the performance of other utilities doing more work.

Performance concerns when heavily used in scripts ?

Posted Mar 19, 2025 10:26 UTC (Wed) by PeeWee (guest, #175777) [Link] (1 responses)

Yes and no, if every call to a uutil incurs that kind of overhead existing scripts will be noticeably slower. But of course things like find and sort may end up being faster, depending on the size of their working set.

At least this is worth having an eye on. If it turns out that the benefits outweigh the downsides, I'd be the last to insist on a fast true in a showstopper kind of way.

Performance concerns when heavily used in scripts ?

Posted Mar 19, 2025 15:13 UTC (Wed) by joib (subscriber, #8541) [Link]

> if every call to a uutil incurs that kind of overhead existing scripts will be noticeably slower.

Will they? Per the original post in this subthread, uutils has an invocation overhead of 4.6s/2000=0.0023s (minus the shell looping overhead). Keep in mind that more complex coreutils utilities will have higher overhead than /usr/bin/true as they need to link in more libraries and map more pages, reducing the relative penalty of uutils. And of course most uses of these utilities actually do more work, amortizing the startup overhead.

> But of course things like find and sort may end up being faster, depending on the size of their working set.

I think things like find, sort, cp etc. will be faster or slower depending on the implementation and tuning choices, algorithms used etc. None of which is impacted by the overhead of launching the binary in the first case.