Speed optimisation

[Kay C Lan]

On 10/7/05, Alex Tweedly <alex at tweedly.net> wrote:

So *if* Rob can accept the missing trailing "0" then Kay is the "winner
> apparent" for the QP (pending any other faster method).



Not so fast:-)

Ithink Alex you were spot on when you said:

3. it's easy to get obsessive about speed beyond the point where it matters
> - I do it all the time !!
>

Having been jolted out of 'reduce the speed' mode when my errors were
pointed out it was time to see what other faults were out there. You've
already mentioned lack of trailing zeros. I note also that only your code
Alex includes a leading zero, ie 03:13:45.0, again, that may or may not be
important. As far as my code not correctly showing hours greater than 24 it
was most definitely a case of looking at the speed and not the output. In a
button I put this code to feed the function, just commenting out the
function I didn't want to run - then read the output from the message box.

on mouseUp
put the ticks into tStartTime
repeat 150000 times
put return & addTime("18:26:43.5",random(20000)) after tMyTime -- Wayne
--put return & addDivandFormat("18:26:43.5",random(20000)) after tMyTime
--Alex
--put return & addTimeAndSeconds("18:26:43.5",random(20000)) after tMyTime--
Dick
end repeat
put (the ticks - tStartTime)/60 & tMyTime into msg
end mouseUp

I would have put a random time in but I just couldn't be bothered so I just
made one up. It just happens that in this case there are only three
instances where the result will exceed 23:59:59. The message box obviously
contained the elapsed time at the top followed by 150000 lines of results. I
was too busy checking the time and a couple of pages of results to not
notice that it never came up with an answer like 27:xx:xx.x

I know some comment has gone back and forward between Dick and Alex about
whether my code can handle negative seconds. Whilst I checked Dick's example
and came to the same conclusion that Alex did - that my code doesn't have
problems with negative seconds, the comments did make me realize that there
was a SERIOUS error with my code.

If someone takes the trouble of recording hh:mm:ss.s then there is a good
chance that the seconds they want to add will also contain a decimal. In
this case my code produces an error regardless of whether you add or
subtract.

I know Rob indicated that he was happly only to add time, which is lucky
because this amended code will not work for subtract:

function addTime pTime,pSeconds
set the itemDelimiter to "."
convert item 1 of pTime to seconds
convert (item 1 of pTime + item 1 of pSeconds) to long time
return it & "." & (item 2 of pTime + item 2 of pSeconds)
end addTime

But when I now run this new code it is about 0.1 seconds slower that Alex's
code!!

So not only does it appear that Alex's code is fastest, it works for both
add and subract AND the format is consistent.

I'll now put away my acceptance speech and return the tuxedo;-)