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

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

Re: expression evaluation problem

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: expression evaluation problem L A Walsh <bash@tlinx.org> - 2019-07-26 03:04 -0700

#15248 — Re: expression evaluation problem

On 2019/07/25 11:15, Ilkka Virta wrote:
> On 24.7. 21:43, L A Walsh wrote:
>   
>>      The important part for me is whether or not it is faster to perform
>> 1 calculation, or 100.  So which would be faster?  In this case
>> execution speed
>> is more important than clarity.  I consider that a 'constraint'.
>>     
>
> Shouldn't it be easy enough to measure how much restructuring that 
> expression affects the execution speed?
>   
---
    Which I did and found a 25% difference using the test case I used.  It
would likely be less in shorter strings, more in longer ones.
> Also, regarding execution speed, I've been led to believe that the shell 
> in general is rather slow, and almost any other language would be better 
> if that is of concern. (awk, Perl, what have you.)
>   
----
    True, assembly would probably be the best choice if that was a sole
concern,
but sometimes I want to have an example of how to do something using only 1
language.  Similarly, many perl modules have versions that require a
compiler to
install, but some that are perl-only can work with perls going back to
5.6 or up
to 5.30 with no recompilation step.  So sometimes there's a desire for
an efficient implementation, while staying within the same language.

    Similarly, by not using some newer bash features, one can have
scripts that
are portable to a wider range of bash versions.




>
>   

[toc] | [standalone]

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

csiph-web