Path: csiph.com!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 17:53:44 -0800
Lines: 41
Approved: bug-bash@gnu.org
Message-ID: <mailman.6434.1545962567.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> <e190ca7a-57a7-5cf5-8001-48806fa98caf@inlv.org> <CABrM6wmgN7+03dvLySy0D=R1PnKwN6-9pM-8mD7VNy8P6u1NLw@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: Martijn Dekker <martijn@inlv.org>, bug-bash <bug-bash@gnu.org>
To: Peng Yu <pengyu.ut@gmail.com>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <CABrM6wmgN7+03dvLySy0D=R1PnKwN6-9pM-8mD7VNy8P6u1NLw@mail.gmail.com>
Precedence: list
Xref: csiph.com gnu.bash.bug:14983

On Thu, Dec 27, 2018 at 5:38 PM Peng Yu <pengyu.ut@gmail.com> wrote:
>
> > I don't believe that at all. The number of positional parameters is kept
> > anyway. It's not recalculated when you compare it to another number, so
> > it's just as fast as a simple comparison of two integers.
>
> Getting the number $# is slow.

How do you determine that? All I ever see in your emails is that you
run things in a loop, get the wall clock and then absolutely declare
that something is slow/fast. That doesn't seem very methodical /
scientific.

* What hardware are you using to test?
* What is the state of the system during your tests?
* Are you also measure variability between runs?
* Are you testing in different hardware architectures?
* Are you testing with different compilers and compiler flags?

Let's say you are doing all of the above. You found that this
particular operation is "slow".

How many times do you execute the operation? Is your program really
spending MOST of its time computing the number of positional
parameters, really? REALLY?

If so, what are you doing? Is it a common enough thing that most of
bash users are going to benefit from this change? No? Just you?


> There is no reason why bash has to be slow. Javascript was slow. But
> it has been optimized to be much faster than it was before.

You do realize that bash is a SPECIALIZED language, not a general
purpose language? This is a poor argument.

In general, I agree that we should look into areas to optimize. You
can see that Chet has been implementing some optimizations over the
years. But the effort should be invested in an area that benefits most
users, not just you trying to do high performance computing in bash.