Path: csiph.com!goblin3!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Eduardo Bustamante <dualbus@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Should [[ -v 1 ]] be supported?
Date: Thu, 27 Dec 2018 21:56:26 -0800
Lines: 32
Approved: bug-bash@gnu.org
Message-ID: <mailman.6443.1545977330.1284.bug-bash@gnu.org>
References: <CABrM6wmrn2gi8_HgmRg67B5nsgGNFRn8Bn-r20MvC-_2LJHZ0g@mail.gmail.com> <5dac2cf2-2fac-0fd1-058f-6a84a3271738@case.edu> <abd86dbc-f6e2-62bd-e9dc-f959e2dbff9f@inlv.org> <CABrM6wkGwVbPdrXTetVsFCiwDPg5JnK4KRh49WqACsKhrrMMdA@mail.gmail.com> <20181228013623.mersdxbzy64dpldp@crack.deadbeast.net> <CABrM6w=2zrjmV24VAgzioAu2iNcyuf3tsi--cfvkCH6MJ7feRA@mail.gmail.com> <20181228015710.tzzbejk36fsgr5wb@crack.deadbeast.net> <CABrM6wkfvTzY5UBMDz_kNr=imV_KpSsFF6o8fV5RLrKMYrPKgg@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: g.branden.robinson@gmail.com, bug-bash <bug-bash@gnu.org>
To: Peng Yu <pengyu.ut@gmail.com>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <CABrM6wkfvTzY5UBMDz_kNr=imV_KpSsFF6o8fV5RLrKMYrPKgg@mail.gmail.com>
Precedence: list
Xref: csiph.com gnu.bash.bug:14987

On Thu, Dec 27, 2018 at 9:45 PM Peng Yu <pengyu.ut@gmail.com> wrote:
(...)
> Yes and no. For a particular bash script, you can quantify which bash
> features are the most time-consuming.
(...)
> (...) But you can not profile all the
> bash scripts that have ever been written. Since there are only limited
> features in bash, in this case, a logical way to go is to at least
> profile each commonly used feature with minimal code (as just for and
> repetitive calling that features as I do) and understand its pros and
> cons.

Err, where did you get this profiling advice from? :) It's not great.

You're just picking arbitrary expressions from a script w/o
understanding how they contribute in terms of % of time spent by your
program, then assume that tuning that is going to produce
*significant* benefits. Furthermore, your testing/measuring is not
really systematic, so the numbers you get aren't really meaningful
(are they specific to your system? or to the way you compiled bash?
are you taking caching and system load into consideration?
variability? etc.)

> (...) A profiler is an overkill in this case.

A profiler is exactly what you need here. You should profile your
script and understand the stuff that actually matters for your goals.
Otherwise you're just chasing unimportant things.

Honestly, if you're not willing to provide more context as to why
these areas should be optimized, then I'm just wasting my time here.