Ed,

>>This said, I can imagine (though this would be very exceptional) that from a performance point of view the INLIST *could* be better.
>>
>
>Walter, you've completely missed the point here. The cost of maintaining the INLIST(), counting the number of args, fixing it when it breaks, changing the code again when the positive and negative numbers have to be the other way negate even an amazingly exceptional performance difference, simply because the performance gain would be completely negligible compared to NO TIME TO MAINTAIN THIS CODE!!!!! A whole minute gained in 3/1000 of a second intervals is completely insignificant compared to maintaining the code!!!!

As ussual we don't seem te communicate with eachother again. As I said you're absolutely right on the maintainability argument, not a doubt about that.

>Performance in this case is a totally fallacious argument. Look at the taks. Assume a 3 minute difference running this a few million times. The odds are if the list changed say, once every 50,000 iterations, and I had to visit the code, and screwed up typing in the change to the list 1% of the time (too much coffee, too little sleep, a cow flew by and jostled my elbow. There was an earthquake! A TERRIBLE FLOOD! IT WASN'T MY FAULT!!!!) probably the corrections and recompiles ate every bit of the time saved. And J Random Clerk updated the list, not yours truly, so it wasn't my fault after all!!!!!!
As for performance, I've got some very interessting mechanisms where performance is very, VERY important.

In one case I've got a personel time tracking mechnism. This person has depending on various factors an amount of leave hours in one year. The mechanism has to deal with date_in_service, date_out_of_service, changing roster, sickness, exceptional leave, normal leave, maternaty leave, etc.
It has to calculate the remaining leave hours for this person.

I could choose for adding an extra field in which the remaining leave hours are stored and recalculate them if something changes in the parameters. But this would probably give performance problems when I change one of the rosters which could apply to numerous persons in various years as I would have to recalcute the extra field. Besides this there is an potential problem that the extra field goes out of sync.

The solution I choose is to calculate the remaining leave (and other data) hours when requested. To maximize performance when the remaining leave hours of large amounts of persons is requested (for e.g. in a report), I've got the whole mechanism tuned for performance and now it takes about 0.03 seconds to calculate the leave hours for one year for one person. I've had to use every trick to save CPU cycles and test various data handling mechanism to accomplish my goal. Within a loop of 366 days each CPU cycle won is important.

The point I'm making is that too me, performance is important in several cases. If one of those cases, i've got to choose between a join which takes more time
than a INLIST and I know there won't be a maintaince problem, i'd go for the inlist.

>I've seen this in threads with you and JimB, who knows this concept absolutely dead cold to rights. None of this crap you're working on or I'm working on will be measurably improved by spending measurable time creebing code to gain 4 CPU cycles per run. It will be measurably improved, as will the sanity of the next guy picking up the code to MAKE THE CODE CLEAN, CLEAR, MAINTAINABLE AND COMPREHENSIBLE. This is why you and I will never agree on our approaches to how to code. You want to xBASE it up, be smarter than the tool, show off how much you know before it happens. I like SQL - it's concise, it's clear, it's maintainable, and in the event that the data is smarter than I am, letting the data engine find the best path to solving the problem based on its knowledge of the state of the data from experience and heuristics rather than my guessed behavior is going to beat the crap out of my programmatic solve based on faulty assumptions. And when it gets too big for VFP I don't have
>to rethink the whole problem.

Ed, I don't think you understand my standpoint. I don't exclusively use xBase construct. Whereever SQL will do the job clean and nicely without significant performance decrease I'll choose SQL. I fully agree on your statement that SQL is far more constructive, clean, consise, etc.

However, I've got several cases (like the one described above) where SQL is getting you nowhere and leads to serious performance problems. Especially where performance is very important, I'll look for alternatives like xBase constructs, which can do the job SQL can't.

The difference between you and me is that I want the fastest tool for the job and you only want to use SQL even in cases where it is doing a very poor job and refuse to even consider an xBase eqiuvalent.

Let's take the following example:

An employee table contains an emp# and a chief#. The chief itself is also an emplyee and also has a chief. The following two examples gets the upper chief of a random employee.

nEmpno=303
lDone=.F.
DO WHILE lDone
   SELECT * FROM Employee WHERE Empno=nEmpno INTO CURSOR x
   IF x.Chiefno=0
      lDone=.T.
   ELSE
      nEmpno=x.Chiefno
   ENDIF
ENDDO

In a XBase construct this could be solved in the following manner.

=SEEK(nEmpno,"Employee","EmpTag")
DO WHILE SEEK(Employee.Chief,"Employee","EmpTag") AND Employee.Chief # 0
ENDO

No doubt that the latter is faster by a mile, espectially when the hierarchy is large.

Walter,