[TIB] Re: A TI-83 research question


[Prev][Next][Index][Thread]

[TIB] Re: A TI-83 research question




> 
> Since I managed to stir up so much controversy with my
> first TI-basic question, here's a hopefully less-challenging
> question.
> 
>   How do the following constructs affect the speed of a
> Basic program on the TI-83 (yes, the "83-")?

When talking about Basic, the difference between 83 and 83+
is extremely small.

> 
>   (1)  While loops as opposed to Repeat loops.
>          I've heard that Repeats are faster, I think,
>          but is this empirically true?

Hmm, I never heard that, but I cannot see why there should
be much difference. I think the other differences (testing
condition at begin/end of the loop, and testing for true/false)
will be more important in optimizing your program.

>   (2)  Breaking out parts of a program into
>        subprograms.
>          In other words, which fragment is faster:
> 
>            prgm:ABCDE           or    prgm:ABCDE
>            :If getKey:Then            :If getKey:Then
>            :*do lots*                 :prgmFGHIJ
>            :*of stuff*                :End
>            :*here*
>            :End                       prgm:FGHIJ
>                                       :*do lots of stuff here*
>                                       :Return

If you have LOTS of programs on your calc, the second might
not be much faster. If there are only a few other programs on
the calc (maybe because your proggie eats up all the space?
;) ) and the "lots of stuff" is really a lot, the second piece of
code is definitely faster.

>   (3)  Using Lbls with Gotos.
>          I've heard that Goto scans the program for
>          Lbls starting at the top and going down.  Is
>          this empirically true?  Does it matter where in
>          the program file the Goto occurs?
>           Are one- or two-character Lbls significantly
>          better with respect to speed?

Yes, whenever a Goto is encountered, the calc searches for the
Label top-down. This means that jumping to a Label close to the
beginning of the program is quicker than to a Label 10,000 bytes
down.
One character Labels are better size wise, I wouldn't know about
speed, but I don't see any reason why parsing would take longer
for one or two characters.

> I'm especially interested in point (2), since my philosophy
> is to keep the number of program files to a minimum.  Rogue
> has two files, one of which contains a subroutine library
> that looks something like this:
> 
>      prgm:ZROGUE
>      If Ans="DESCMONSTER
>      Goto DM
>      If Ans="DESCOBJECT
>      Goto DO
>      If Ans="TRYMOVE
>      Goto TM
>      Lbl DM
>      name of monster -> Str1
>      Return
>      Lbl DO
>      ...
> 
> Then when I need to print a message, I can call the subroutine:
> 
>      prgm:ROGUE
>      ...
>      "DESCMONSTER
>      prgmZROGUE
>      Disp "THE "+Str1+" HITS!

Obvious: Don't use "DESCMONSTER, use "DM instead, this will save many
bytes in your program.

> It would probably speed up the game to break out the subroutines
> into prgmZDMONST, prgmZDOBJ, prgmZTRYMOVE, and so on, but would the
> annoyance to the player (at having his calc Prgm menu be filled with
> the programmer's subroutines) be worth the speed-up?  That's why I
> want to know about empirical tests of point 2 in particular.

In my experience, many people are somehow unable to grasp the
concept of multiple files for one program. Especially my class mates
that don't know much about the calc in the first place had a lot of
trouble with my programs that used more than one file.
The possible annoyance is much of the reason for the Z... thing. All
subprograms will end up at the bottom of the list, so annoyance
shoould be limited. However, as I mentioned above, I can vividly
imagine some of my classmates saying "Rogue doesn't work, can you
help me?" (Well, they'd ask it in Dutch of course :) )
At least name all you subprograms ZR... so at least people who know
what they're doing know what programs belong to ROGUE.

> Thanks,
>  -Arthur
> 

Hope you'll like my answers better this time :)
Rob van Wijk

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net




References: