May the numbers speak

Let's find out the difference between my
and "Mark Twain" 's approach to the solution
of "parsing 'time string' task". For simplicity
I'll do everything using DX Forth.
My solution is:
VARIABLE C6
VARIABLE C1
: TIMESTRSCAN ( addr count -- d )
  1 C6 !  1 C1 !
  >R >R 0 0 R> R>
  OVER + 1-
  DO
    I C@ DUP 58 =
    IF
      DROP
      C6 @ 60 * C6 !
      1 C1 !
    ELSE
      48 - C1 @ * C6 @ M* D+
      10 C1 !
    THEN
  -1 +LOOP
;
(the only change for ANS-Forth were
 slightly different two VARIABLE lines,
 I have no idea what kind of problem Ed
 met with the loop)
Mr. Fifo's proposal:
: dtimescan
   over swap chars + >r >r 0. r> 0 begin
     over r@ <
   while
     over c@ [char] : =
     if
       swap >r s>d d+ 60 1 m*/ r> 0
     else
       10 * over c@ [char] 0 - +
     then
     swap char+ swap
   repeat r> drop nip s>d d+
;
OK, now we need to time both solutions.
So let's create the timing words:
: TLOOP1
  TICKS PAD 8 30000 0 DO 2DUP TIMESTRSCAN 2DROP LOOP
  2DROP TICKS 2SWAP D- D. ;
: TLOOP2
  TICKS PAD 8 30000 0 DO 2DUP dtimescan 2DROP LOOP
  2DROP TICKS 2SWAP D- D. ;
Now let's take it away:
S" 12:34:56" PAD SWAP CMOVE  ok
TLOOP1 61  ok
TLOOP2 10  ok
Ooops! Not too good. It seems variables are
pretty "expensive" thing in DX Forth. So let's
optimize the thing a little, quite basic way:
: TIMESTRSCAN1 ( addr count -- d )
  1 C6 !  1 C1 !
  >R >R 0 0 R> R>
  OVER + 1-
  DO
    I C@ DUP 58 =
    IF
      DROP
      [ C6 ] LITERAL @ 60 * [ C6 ] LITERAL !
      1 [ C1 ] LITERAL !
    ELSE
      48 - [ C1 ] LITERAL @ * [ C6 ] LITERAL @ M* D+
      10 [ C1 ] LITERAL !
    THEN
  -1 +LOOP
;
: TLOOP3
  TICKS PAD 8 30000 0 DO 2DUP TIMESTRSCAN1 2DROP LOOP
  2DROP TICKS 2SWAP D- D. ;
How does it do now?
S" 12:34:56" PAD SWAP CMOVE  ok
TLOOP3 16  ok
So according to the rule: "Once twp implementation
 techniques provide performance within (say)
 a factor of 1.5 or 2 of each other, I stop worrying.
 Short words are better than long ones." - I still
dare to express the opinion my solution is better.
Besides: only recently some "Master of Forth" explained:
"you have to know that good software comes with MANY
 qualities, speed being only one of them. If I have to
 choose between correct and fast, there has to be a very
 convincing argument for the speed requirement.
 They didn't tell you that in your college? Oh dear. I'm
 so sorry for you! You must have had a miserable life."
So taking the above into consideration, the
slightly slower pace of my (optimized) solution
doesn't really matter. No further optimization
really necessary, in fact.
--