Ok fellow propeller-heads, I've got a case (no pun intended) of elegance
over efficiency. Which is more efficient?

Sample1:
FOR II = 1 TO 100
MASSAGE SOME DATA per II
SET COUNTER per II
BEGIN CASE
CASE SOMETHING1
DO STUFF1 WITH II,DATA,COUNTER
CASE SOMETHING2
DO STUFF2 WITH II,DATA,COUNTER
CASE SOMETHING3
DO STUFF3 WITH II,DATA,COUNTER
CASE SOMETHING4
DO STUFF4 WITH II,DATA,COUNTER
CASE SOMETHING5
DO STUFF5 WITH II,DATA,COUNTER
END CASE
NEXT II

Sample2:
BEGIN CASE
CASE SOMETHING1
FOR II = 1 TO 100
MASSAGE SOME DATA per II
SET COUNTER per II
DO STUFF1 WITH II,DATA,COUNTER
NEXT II
CASE SOMETHING2
FOR II = 1 TO 100
SET COUNTER per II
MASSAGE SOME DATA per II
SET COUNTER per II
DO STUFF2 WITH II,DATA,COUNTER
NEXT II
CASE SOMETHING3
FOR II = 1 TO 100
MASSAGE SOME DATA per II
SET COUNTER per II
DO STUFF3 WITH II,DATA,COUNTER
NEXT II
CASE SOMETHING4
FOR II = 1 TO 100
MASSAGE SOME DATA per II
SET COUNTER per II
DO STUFF4 WITH II,DATA,COUNTER
NEXT II
CASE SOMETHING5
FOR II = 1 TO 100
MASSAGE SOME DATA per II
SET COUNTER per II
DO STUFF5 WITH II,DATA,COUNTER
NEXT II
END CASE

I'm thinking Sample2 is more efficient because there are only five case
scans vs an average of 2.5 x 100 case scans in Sample1. But I hate to employ
the same code over and over. Sample1 looks nicer, but the thought of all
those CASE tests is giving me the willies.

Which one and why?

Thanks!

Ed

A third possibility is to make a function of the repeated code. But I would
probably go with sample one because it looks easier to maintain and there
isn't much to be gained by optimizing the code with modern machines.
Different strokes for different folks.
BobJ

"Ed Sheehan" <NOedsSPAM (AT) xmission (DOT) com> wrote

On May 17, 11:50*am, "BobJ" <bobjos... (AT) hotmail (DOT) com> wrote:
A third possibility - is a for/next faster or slower than a loop/
repeat.

Eugene

Why don't you plug in some data & tell us?!?!?

Tooooooo many unknowns, like platform, what DOSTUFF actually does,
placement of code in memory (eg: may cross a frame boundary & cause
frame faults)

You have already given an answer that seems logical(ish) ..... but I'd
suggest for a lopp of 100 items on a system installed this
century .... does it really matter??!?!

Slow news day?!?

Summary - doesn't matter much for this example.

The CASE statement usually gets parsed into a series of IF statements.

Sample2 assumes the SOMETHINGn condition doesn't change between
iterations. If this is true, then sure, I think Sample2 is a little
more efficient for the runtime if the compiler is non-optimizing, or
(more likely) if the optimization is simplistic.

Sample1 assumes that SOMETHINGn will change within the loop. If
that's not the case there's no sense in checking it on every
iteration. Bob is correct that some compiler/runtime optimizations
will detect that a check for a never changing condition is being made
and they'll refactor the code a bit. So if you do have a smart
compiler (unlikely unless maybe with jBase), Sample1 and Sample2
should execute the exact same object code.

For readable and non-redundant code, I'm with Bob and would go for
something like this:

DO.PROCESS = 1
BEGIN CASE
CASE S1
* setup custom vars for common processing
CASE S2
* more custom vars for common processing
CASE S3
* unusual
GOSUB PROCESS.DATA.UNIQUE1
DO.PROCESS = 0
CASE 1
DO.PROCESS = 0
END CASE
IF DO.PROCESS THEN GOSUB PROCESS.DATA
....
PROCESS.DATA:
FOR II=1 TO 100
* common processing
NEXT II
RETURN
PROCESS.DATA.UNQIUE1:
FOR II=1 TO 100
* special processing
NEXT II
RETURN



"BobJ" wrote:
On that I must disagree. Nothing replaces good code. You can't rely
on tiers of BASIC compiler, BASIC runtime, OS, and CPU to optimize
your code for you.

That said, Bob is correct that these days readability has a higher
standing than in the past over coding for efficiency. For example,
the days of this are over:
J=1;K=1;GS 10
(in BASIC anyway)
That's replaced by:
INVOICE.COUNTER=1
LINE.ITEM.COUNTER=2
GOSUB PROCESS.LINE.ITEM
Verbose source doesn't translate to verbose object.

Some compilers can eliminate things like unreferenced variables, empty
loops, and redundant assignments, but only experimentation and
performance monitoring will tell you how optimized your code is - you
simply can't blindly trust any tier.

Back to the original problem, yeah, sometimes form trumps efficiency -
if I were writing that code in OOP I might use a State Engine , which
has a lot more code but it's much more versatile in that adding new
SOMETHINGx conditions wouldn't require a change to the original code.
YMMV

T

Ok, here's more of what I'm actualy doing:

There are web page click behaviors and user statuses, where one of five
conditions are met. Each of these condidions invoke a webservice call to
retrieve XML data related to these behaviors. The case statements are
pulling the method tags from the returned data, and then extracting values
from the subtags in that data. So CASE SOMETHINGn will have only five
possibilities and will always be the same five conditions. My 100 loop is
worst case; usually much less than that. DO STUFF just extracts the values
and applies business rules to them.

My goal is to 1) write acceptably-efficient code, and 2) maintain
readability. Perhaps efficiency won't affect the loop/case construct
methodology in the real world. I suppose I'll end up running samples through
an external loop and get timings. Time is important, but I may be dabbling
in the last 2 percent of what I can hope for. I already employed something
I've never used before: REMOVE. I've not needed to parse (in Universe Basic)
such large amounts of data before (>1MB). REMOVE keeps the pointer
positioned in a dynamic array as you pull data. Nice.

Anyway, thanks for your responses. I still think casing so much uses more
clock cycles, but the tidier code in Sample1 may be worth it.

Ed

"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

I use flags all the time and I'm not embarrassed. The intent is "do
this thing all the time unless something determines otherwise". If I
were coding it for a real project I might GoSub into the routine and
Return out if there's nothing left to do. That wasn't the focus of
this exercise.

IIRC I haven't used GOTO in a decade, in any language, except to get
out of code that someone else trapped me into. I simply don't find it
elegant or necessary. YMMV

T

On May 20, 1:21*pm, "Ed Sheehan" <NOedsS... (AT) xmission (DOT) com> wrote:
figure out the most efficient way to make it work. The problem with
cost per instruction is it varies widely by flavor of MV. Some
systems cache the reads/writes better than others thereby making them
very fast (I once added a single attribute to 11 million records on
jBase in 14 seconds, on D3 it would take substantially longer). Also,
the method of compiling and execute the code makes a difference
(pseudo-compile or full compile).

One thing I have found with string extraction is that on many system
is it faster to convert a character in the string to an MV delimiter
then pull it apart with var<> constructs. Some MV flavors create a
very efficient data structure in memory of a dynamic array rather than
just parse the string. So one time through the string, then it's just
a linked-list (or similar) traversal which is very fast. Also, O/S
tools can be very handy, like in Unix I love to use the "tr" command
to do an initial translation of a large string and then process that
string in MV or even do some work in Perl or Python then pass in a
massaged data set. The string management in other languages can be of
great benefit many times.

M><

On May 17, 7:29*am, "Ed Sheehan" <NOedsS... (AT) xmission (DOT) com> wrote:
Elegance??? Well, relatively, speaking...

Ed, I'm sure you'll agree, they both look ugly! I don't know --
if I had to, I'd error on the "TALL and THIN!" -- depending on how
much I had to drink. If the only choice is that you must flip a coin
between your two scenarios, plug in specifics and then put some actual
timers on it to see if it was worth the trouble of worrying-- end of
story.

Definitely, in your scenario, it's probably better to spend ALL
"optimization effort" on the overall meat and maintainability, rather
than the structure. Also, although you've concluded and deduced and
average of 2.5 Case instructions per iteration (in Sample1), you
haven't actually substantiated that frequency distribution across the
CASES as a given.

I would bet there's at least a third scenario... that if you plugged
in actual statements here, you can probably keep the CASE statement
outside the FOR-NEXT -and- also keep from having to replicate
instances of the FOR-NEXT for each CASE statement. I'm more intriqued
by the problem your trying to solve, than the two solution choices
present.

-Dave