Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14982 > unrolled thread

Re: Should [[ -v 1 ]] be supported?

Started by"G. Branden Robinson" <g.branden.robinson@gmail.com>
First post2018-12-27 20:57 -0500
Last post2018-12-27 20:57 -0500
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Should [[ -v 1 ]] be supported? "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2018-12-27 20:57 -0500

#14982 — Re: Should [[ -v 1 ]] be supported?

From"G. Branden Robinson" <g.branden.robinson@gmail.com>
Date2018-12-27 20:57 -0500
SubjectRe: Should [[ -v 1 ]] be supported?
Message-ID<mailman.6433.1545962563.1284.bug-bash@gnu.org>

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web