I wasn't asking anything. I was making a statement regarding the previous post.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Sunday, October 09, 2005 10:32 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Fw: More U2 programming hints Are you asking if there's a difference between a BASIC SELECT and an EXECUTE "SELECT"? I don't want to answer the wrong question. But I and others have the answer if it's this one. I guess this diverts the question of how to best protect the intregrity of the entire file when processing the entire file for the possiblilites of additions or deletions. Neither BASIC SELECT or EXECUTE SELECT is a clear cut winner. I don't know enough about FILE.LOCK but it sounds likely. My 1 cent. ----- Original Message ----- From: "gerry-u2ug" <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> Sent: Sunday, October 09, 2005 9:39 PM Subject: RE: [U2] Fw: More U2 programming hints > That's ridiculous. > How is a BASIC select any different from a EXECUTE select in this regard ? > When you do an EXECUTE "SELECT ..." a select list is built. > As you process this list, records could be added that will not appear in the list. > Conversely, records that have been selected could be deleted and no longer exist when the list is processed. > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jeff Marcos > Sent: Sunday, October 09, 2005 08:26 PM > To: u2-users@listserver.u2ug.org > Subject: [U2] Fw: More U2 programming hints > > > I must agree that a BASIC SELECT is quicker but... Don't you run the risk of > missing groups (in the read function) in this type of select? If users are > updating this file they could insert data into a group which you may already > passed. > > > > You would only use this type of select when no one is updating this file. > > > > Regards, > > Jeff Marcos > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] On Behalf Of Mark Johnson > > Sent: Thursday, 6 October 2005 10:26 PM > > To: u2-users@listserver.u2ug.org > > Subject: Re: [U2] Fw: More U2 programming hints > > > > > > I can't see how a BASIC SELECT can be slower than EXECUTE "SELECT". It > > doesn't have to go through to get 'xxx items selected' before it processes > > the first one. I also don't believe the mechanical difference once it > > begins, ie 'find the next group' etc. Wouldn't you think that this at least > > spares the actual hashing as it is navigating through the file sequentially. > > > > I would really like to see a great proof program against BASIC SELECT. I > > often replace EXECUTE "SELECT" with a BASIC SELECT over the years *because* > > it has always ran faster, regardless of platform. I've had many > > opportunities to be proven wrong. I've tested every replacement and have > > always reported an improvement. > > > > Thanks. > > MarkJohnson > > ----- Original Message ----- > > From: "Allen E. Elwood" <[EMAIL PROTECTED]> > > To: <u2-users@listserver.u2ug.org> > > Sent: Tuesday, October 04, 2005 5:45 PM > > Subject: RE: [U2] Fw: More U2 programming hints > > > > > > > This is the way it was explained to me way back in '88. The internal > select > > > is slower on the whole file, but immediate in response. It works the same > > > as LIST. If I list a file with 2,000,000 records I get immediate > response. > > > > > > If I want to process an entire file, then external select is slower on > > > response, i.e. I have to wait for 2 million records to be selected before > > > processing begins, but is quicker in processing all records. > > > > > > The internal is slower due to the system having to stop what it's doing, > > > find the next group, break out the individual ID's from that group, and > then > > > return it to the program - over and over again as it makes it's way > through > > > the file. > > > > > > hth! > > > > > > Allen > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> Behalf Of Stevenson, > > > Charles > > > Sent: Tuesday, October 04, 2005 14:24 > > > To: u2-users@listserver.u2ug.org > > > Cc: Louis Windsor > > > Subject: RE: [U2] Fw: More U2 programming hints > > > > > > > > > This is a bit disconcerting. > > > BASIC SELECT should be faster than EXECUTE "SELECT..." > > > Maybe the smart people can weigh in on this: > > > > > > > From: Louis Windsor > > > > > > > > A few years ago we used the BASIC SELECT FILE as opposed to > > > > the EXECUTE "SELECT FILE". > > > > > > > > We updated UniVerse (don't ask from what version to what > > > > version as I don't remember) and overnight ALL our programs > > > > ran five or six times longer. > > > > > > Completely contrary to my experience and counter-intuitive, too. > > > > > > > We were told (by VMark) that the BASIC SELECT now selected > > > > each group but it could be optioned to work the "old" way. > > > > > > Hmmm, do I vaguely, hazily remember something about that? Maybe on > > this > > > list? Maybe in release notes? No uvconfig option jumps out at me. > > > I don't think flavor would matter, or $OPTIONS [-]VAR.SELECT. > > > $OPTIONS FSELECT would slow the BASIC SELECT down to approximately > > the > > > same as EXECUTE "SELECT...", but not make it slower. > > > Louis, do you, perchance, use $OPTIONS FSELECT? Maybe buried in a > > > $include file common to every program? > > > > > > > I wrote a conversion program to change ALL BASIC SELECTs to > > > > executed SELECTs in the source and recompiled and that is the > > > > way we have done it ever since. > > > > > > > > I don't know if things are different now but we have grown to > > > > prefer EXECUTEd selects as selection criteria can be included. > > > > > > Louis, can you run a simple benchmark and see if this is still true? > > > Or show us an example of your own? > > > > > > INTERNAL: > > > OPEN "[really big file]" TO F ELSE STOP > > > CRT 'I1', TIMEDATE(), SYSTEM(9) > > > SELECT F > > > CRT 'I2', TIMEDATE(), SYSTEM(9) > > > LOOP WHILE READNEXT ID > > > READ REC FROM F, ID ELSE NULL > > > REPEAT > > > CRT 'I3', TIMEDATE(), SYSTEM(9) > > > > > > EXECUTED: > > > OPEN "[really big file]" TO F ELSE STOP > > > CRT 'E1', TIMEDATE(), SYSTEM(9) > > > EXECUTE "SELECT [really big file]" > > > CRT 'E2', TIMEDATE(), SYSTEM(9) > > > LOOP WHILE READNEXT ID > > > READ REC FROM F, ID ELSE NULL > > > REPEAT > > > CRT 'E3', TIMEDATE(), SYSTEM(9) > > > > > > (Run each a couple times, to allow for i/o differences in loading data > > > buffer cache.) > > > > > > There should be virtually no elapsed time between I1:I2 above, but long > > > elapsed time between E1:E2. > > > I expect I2:I3 to approximately equal E2:E3. > > > > > > > > > Let me explain why this is counter-intuitive. > > > > > > Normally, the BASIC SELECT statement itself does not actually do any > > > select on the file. It merely sets things up behind the scenes so that > > > subsequent READNEXTs each get the next id from the file opened to > > > F.FILE, ("next" meaning as stored on disk). > > > UV keeps track of where it is in the file, unbeknownst to you. Sorta > > > like it keeps track of where it is for REMOVE or attribute-level > > > EXTRACTs. > > > > > > > > > > > > Exceptions to internal being faster than executed: > > > > > > 1.SSELECT FILEVAR (i.e., 2 S's, SortSelect). > > > You gotta read the whole file First to sort the keys. > > > (and it's an alpha-type sort, even for numeric keys.) > > > > > > 2. $OPTIONS FESLECT > > > Makes SELECT FILEVAR populate @SELECTED and to do so means traversing > > > the file. > > > > > > 3. Louis Windsor. Poor bloke, they're out to get him. > > > > > > > > > Chuck Stevenson > > > ------- > > > u2-users mailing list > > > u2-users@listserver.u2ug.org > > > To unsubscribe please visit http://listserver.u2ug.org/ > <http://listserver.u2ug.org/> > > > ------- > > > u2-users mailing list > > > u2-users@listserver.u2ug.org > > > To unsubscribe please visit http://listserver.u2ug.org/ > <http://listserver.u2ug.org/> > > ------- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > <http://listserver.u2ug.org/> > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
