Efficiency...

[crunchy1]

def var v-logical as log no-undo.

In terms of efficiency which version of the test is better. And why?

(A) if v-logical = no then do: ...

(B) if not v-logical then do: ...

 

[John Nebi]

Depends upon how many angels you can fit on the head of a pin ....:awink:

 

[mpowell_esq]

The more efficient use would be;
* (A) if v-logical = no then do: ...
This is because the compiler is making the comparison on the first iteration. v-logical is compared initialy. If v-logical = no then ... (comparison check) As apposed to NOT v-logical = no then ... (comparison check + NOT iteration). Also reading your code example used. The var names old methods. vLogical / viLogical would be more appropriate.

 

[joey.jeremiah]

Your question should go in the assembly forum ( that brings back memories )

You've completely missed what Progress was designed and intended for. It's an interpreted ( vm and byte-code ), 4GL, business language ... it's designed for power, flexibility etc. to make writing business apps easier.

I think, I get where you're going with this. Is flipping a logical value, or comparing logical values faster ? just do a loop of say 100,000x.

But it's ridiculous and unless it's the only operation in the loop, proc etc. almost any other operation would be, relatively, much more expensive e.g. invoking procedures and functions.

I would write it in a way that would make the conditions meaning most obvious and clear for the next guy who'll need to work on the prog, even if it costs a few extra microseconds.

Just out of interest what are you using progress for ?

 

[it@flude.co.uk]

Certainly, if you are using it in an index, then use the "= no" syntax.

for each whatchumcallit where whatchumcallit thingamyjig = no no-lock:
end.
is far more efficient than
for each whatchumcallit where not whatchumcallit thingamyjig no-lock:
end.

Simon

 

[joey.jeremiah]

Certainly, if you are using it in an index ...

Hope not.

Logical fields in indexes, in almost all cases, are a bad idea.

 

[it@flude.co.uk]

May I ask why?

We differentiate live items from deleted items by having live and deleted flags which are often part of indices.

Simon

 

[joey.jeremiah]

If you have a 1,000,000 records and 500,000 of them have the same
value, putting an index on that value won't do much good.

A typical approach is to add that info to a word-indexed description
field. But ofcourse in Progress for every 2 people there are 3 diff opinions.

 

[ddavis]

Mostly I agree with you Joey, and I make the same argument that indexing on a logical field doesn't usually make a lot of sense, but...

In the case where 98% of your records are no, and you really want to filter to the yes records, an index on a logical field can be a very efficient way to do it.

If the split is more like 40/60 or 50/50, then the index is just more overhead.

I also agree that for every two people, there's three opinions... I just shared two of mine.

 

[it@flude.co.uk]

Typically, in some form of interface transaction, you would have exactly that - current records waiting to be processed would have a logical field set as no, processed records would be set to yes.

You wouldn't want a logical field in a unique index, though - I saw a databse with several key field in a unique index followed by a live logical field. It allowed the user to create a new record with the same key fields as a current record, as long as live = no, or lve = ?. It caused chaos with the resulting reports.