efficiency

efficiency

[Ray Andrews]

Gentlemen:


echo "\nSTOP TIMER. REAL RUNTIME: $((now-start)) MILISECONDS 
($(((now-start)/60000)):${(l:2::0:)$(((now-start)/1000%60))}) $@"

integer -x base=$(((now-start)/1000))
echo "\nSTOP TIMER. REAL RUNTIME: $((now-start)) MILISECONDS 
($(($base/60)):${(l:2::0:)$(($base%60))}) $@"

... is there any real advantage to the second line?  Obviously I'm 
trying to cut down on duplicate calculation, and in the real world it 
hardly matters, but as a point of principal, which is better?

Re: efficiency

[Peter Stephenson]

On Fri, 03 Feb 2017 18:55:53 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:
> echo "\nSTOP TIMER. REAL RUNTIME: $((now-start)) MILISECONDS 
> ($(((now-start)/60000)):${(l:2::0:)$(((now-start)/1000%60))}) $@"
> 
> integer -x base=$(((now-start)/1000))
> echo "\nSTOP TIMER. REAL RUNTIME: $((now-start)) MILISECONDS 
> ($(($base/60)):${(l:2::0:)$(($base%60))}) $@"
> 
> ... is there any real advantage to the second line?  Obviously I'm 
> trying to cut down on duplicate calculation, and in the real world it 
> hardly matters, but as a point of principal, which is better?

The point of principle here is "don't repeat yourself"; it's better to
do every calculation just once.  Probably the main reason for this is
what happens if you decide you need to change the calculation.  (For
example, you might decide to round the calculation differently.  I'm clearly
not suggesting you need to!)  Then you only need to change one place.
Getting used to that does help you avoid pitfalls in less trivial cases...

pws

Re: efficiency

[Ray Andrews]

On 04/02/17 07:05 AM, Peter Stephenson wrote:
> On Fri, 03 Feb 2017 18:55:53 -0800
> Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> The point of principle here is "don't repeat yourself"; it's better to
> do every calculation just once.  Probably the main reason for this is
> what happens if you decide you need to change the calculation.  (For
> example, you might decide to round the calculation differently.  I'm clearly
> not suggesting you need to!)  Then you only need to change one place.
> Getting used to that does help you avoid pitfalls in less trivial cases...
>
> pws
>
Thanks Peter.  Yes I understand that as a point of general programming, 
I think what I was really asking is if, in an interpreted language the 
time spent calculating is offset by the time spent parsing.  That is, in 
C you'd be more efficient doing the calculation once (besides what you 
say above), but maybe in zsh the important thing is to reduce the number 
of lines or the number of variables or something like that.  Or, on the 
contrary, maybe the simpler form is doubly better since the lines are 
shorter and thus save parsing time as well as calculation time.

Actually, I just realized that the thing can time itself:

$ . ./timer; timer start; timer start; timer; timer stop; timer stop

, so I tried both ways and:

echo "\nSTOP TIMER. REAL RUNTIME: $((now-start)) MILISECONDS
($(((now-start)/60000)):${(l:2::0:)$(((now-start)/1000%60))}) $@"

... turns out to be faster by a whopping milisecond or two, which 
surprises me.  But as you say, the other way is better code of course.  
This isn't important, I'm just curious.

Re: efficiency

[Peter Stephenson]

On Sat, 04 Feb 2017 07:39:28 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:
> I think what I was really asking is if, in an interpreted language the 
> time spent calculating is offset by the time spent parsing.  That is, in 
> C you'd be more efficient doing the calculation once (besides what you 
> say above), but maybe in zsh the important thing is to reduce the number 
> of lines or the number of variables or something like that.  Or, on the 
> contrary, maybe the simpler form is doubly better since the lines are 
> shorter and thus save parsing time as well as calculation time.

Typically, in a real script, you'd find the difference in time made so
little difference having it look neat was preferable.  You'd only start
looking at optimisations if this was in an inner loop and had to run
many times; or was in a function that lots of users had to run very many
times a day; or involved a significantly larger amount of data if done
one way rather than the other; or something like that.

I'm sure this has come up before, but if you're in a position where a
saving of this kind is important, there's a good chance you shouldn't
really be using a shell at all.

pws

Re: efficiency

[Ray Andrews]

On 04/02/17 07:47 AM, Peter Stephenson wrote:
>
> I'm sure this has come up before, but if you're in a position where a
> saving of this kind is important, there's a good chance you shouldn't
> really be using a shell at all.

Of course.  Still it's good to understand the theory of the thing. As I 
said, in practice the difference was a milisecond but I backed the wrong 
horse, which is instructive since it suggests that the shell likes fewer 
lines more than it likes simplified calculation. Just curious.  In 
practice I'll always go for robustness and better code style.

Re: efficiency

[Peter Stephenson]

On Sat, 04 Feb 2017 08:38:52 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:
> Of course.  Still it's good to understand the theory of the thing. As I 
> said, in practice the difference was a milisecond but I backed the wrong 
> horse, which is instructive since it suggests that the shell likes fewer 
> lines more than it likes simplified calculation.

Yes, that does sound right.  In an interpreted language quite a lot of
the overhead is that you need to start from scratch on each line of
input, working out what it is and passing through the hierarchy first of
parsing and then execution.  The math expression is interpreted, too,
and has its own parsing and execution phases, but in a significantly
more limited way.  The actual time taken adding, subtracting and
dividing to do the calculation within that is utterly trivial,
I should think nearer nanoseconds than microseconds.

pws

Re: efficiency

[Ray Andrews]

On 04/02/17 08:47 AM, Peter Stephenson wrote:
> On Sat, 04 Feb 2017 08:38:52 -0800
> Ray Andrews <rayandrews@eastlink.ca> wrote:
>> Of course.  Still it's good to understand the theory of the thing. As I
>> said, in practice the difference was a milisecond but I backed the wrong
>> horse, which is instructive since it suggests that the shell likes fewer
>> lines more than it likes simplified calculation.
> Yes, that does sound right.  In an interpreted language quite a lot of
> the overhead is that you need to start from scratch on each line of
> input, working out what it is and passing through the hierarchy first of
> parsing and then execution.  The math expression is interpreted, too,
> and has its own parsing and execution phases, but in a significantly
> more limited way.  The actual time taken adding, subtracting and
> dividing to do the calculation within that is utterly trivial,
> I should think nearer nanoseconds than microseconds.

But the microseconds were for the entire function to execute several 
times, which is far more than just the math.
>
> pws
>
Excellent, that's my lesson.