Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14984 > unrolled thread
| Started by | Peng Yu <pengyu.ut@gmail.com> |
|---|---|
| First post | 2018-12-27 19:47 -0600 |
| Last post | 2018-12-27 19:47 -0600 |
| 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.
Re: Should [[ -v 1 ]] be supported? Peng Yu <pengyu.ut@gmail.com> - 2018-12-27 19:47 -0600
| From | Peng Yu <pengyu.ut@gmail.com> |
|---|---|
| Date | 2018-12-27 19:47 -0600 |
| Subject | Re: Should [[ -v 1 ]] be supported? |
| Message-ID | <mailman.6435.1545962583.1284.bug-bash@gnu.org> |
On Thu, Dec 27, 2018 at 7:37 PM G. Branden Robinson <g.branden.robinson@gmail.com> wrote: > > At 2018-12-27T18:39:26-0600, Peng Yu wrote: > > What I meant in my original email is that I want something for testing > > if there is a command line argument (one or more, the exact number > > does not matter). $# gives more than that info, because it tells not > > only whether is any command line argument, but also how many. This > > could lead to slower performance if the goal is to just test if there > > is an argument. > > You should look into how integer comparisons are done in hardware. > > For instance, comparison and subtraction operations are often comparable > (or even identical) in cycle count because they both perform a > subtraction "under the hood". You need to be programming in assembly > language to influence execution at such depths. > > See, e.g., > > https://www.quora.com/What-is-the-difference-between-cmp-and-sub-instruction-in-8086microprocessor > > 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. There are many more that I have already tested. You can not dismiss this one just because it may not have a large impact. -- Regards, Peng
Back to top | Article view | gnu.bash.bug
csiph-web