At 2018-12-27T19:47:08-0600, Peng Yu wrote: > On Thu, Dec 27, 2018 at 7:37 PM G. Branden Robinson > > As others have noted, if you are worried about marginal performance > > impacts this small, margin you are probably writing in the wrong > > language, or distracting yourself with tiny details when you do not even > > know the cyclomatic complexity of your code or the big-O classification > > of your algorithms. > > > > Attack those problems first, and see what you discover. > > The problem is that bash is not systematically profiled for > performance at all. I am doing it step it by step.
You're whacking moles. Use a profiler. That's what they're for. https://www.thegeekstuff.com/2012/08/gprof-tutorial/ > There are many more that I have already tested. You can not dismiss > this one just because it may not have a large impact. Yes, I can. You need to identify where bash is _actually_ spending most of its execution time, and a profiler can help you do that. You also need to establish acceptance criteria. All but the most finely-tuned code can be made more performant; often raw performance comes at a cost, such as the abandonment of memory safety. Aliasing problems are one example in software, and the Spectre and Meltdown suites of cache-related timing attacks are an examples from hardware. What is it you're trying to achieve? State your goal in terms that are "SMART": (S)pecific (M)easurable (A)ttainable (R)easonable (T)imely Just the first four would be a good start. Regards, Branden
signature.asc
Description: PGP signature
