RPL programming questions
|
02-19-2014, 05:23 PM
Post: #13
|
|||
|
|||
RE: RPL programming questions
(02-19-2014 02:15 PM)HP67 Wrote: I may have misread David's comments but I thought he posted times for his User RPL version using local variables. That's what I intended to ask about. David said "My 50g gives times of 23 secs for TGLO2 and 21 secs for TLOC2" and I was comparing that to Peacecalc's stack example where Peacecalc said "this proggie create five values on stacklevel one to five and in the loop these variables are recalled by PICK and immediately afterwards deleted." That took 26 seconds. You didn't misread my comments. The 23/21 sec. times were for the UserRPL programs that were re-coded without the single quotes around the variable names (and the subsequent RCL). Keep in mind that these are very specific (and useless) programs that are attempting to time some very specific actions. Real examples would more likely have a blend of operations that would tend to minimize some of the time differences. I was simply trying to make the examples more realistic in terms of how you would code them; instead of writing code like this: Code: 'A' RCL 3, * 'B' RCL + you would almost certainly want to use this: Code: A 3, * B + The latter is both faster and easier to read (my opinion, of course). Even better for readability might be: Code: ob1Height 3, * But the above would be slightly slower and take up more memory. Is it worth it? As the programmer, you have to make that decision. If you're working on something that is likely to be updated later, it may be. If the above is in a tight loop that is executed thousands of times, the speed penalty may be excessive. Using stack operations (instead of named variables) to speed things up gains efficiency more from the standpoint of how you sequence your operations than from looking at the stack as storage area to PICK things from. Stack operations such as SWAP, DUP, ROT, DUP2, etc. are very fast. So doing something like this: DUP2 + will be faster than this: A B + But as you can see, the former requires that the variables are already on the stack at the outset. The penalty for using stack-based operations is as has been mentioned by others: readability and code maintainability suffers. These are important factors that should not be discounted when considering how you write any application (on any platform). A program written with a bias toward using stack operations may be more efficient than one using local variables, but in most cases it will also be more fragile. Adding a new computation in the middle of previously written ones can wreak havoc with your carefully planned stack. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 2 Guest(s)