I've run into that scenario before and choose to use EXECUTE SELECT to lock-and-load the active list. It only comes up when writing new records that hash later in the same file (non-predictable).
99% of the time the beginning to end SELECT is to summarize or analyze something. The other 1% should be regarded as well. My 1 cent. ----- Original Message ----- From: "Bruce Nichol" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Sunday, October 09, 2005 10:04 PM Subject: Re: [U2] Fw: More U2 programming hints > Goo'day, > > At 10:25 10/10/05 +1000, you wrote: > > >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. > > The major thing that one should be aware of using an EXECUTEd "SELECT > filename" versus BASIC SELECT is that "SELECT filename" goes off and > selects a finite number of records from the file BEFORE PROCESSING STARTS > and works only with that list during processing, whereas a BASIC SELECT > gets a group at a time from the file whilst processing. The latter > (BASIC SELECT) can cause problems if, as a result of your processing, > you're writing NEW records back to the file, or writing the same record > back with a new @ID, and you're writing them into groups the BASIC SELECT > has yet to process... They'll get picked up and processed with the rest of > the group as if they were there all the time..... > > If that happens to you, then the least important thing you're concerned > about is speed...... > > > > > > >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: [email protected] > > > >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: <[email protected]> > > > >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: [email protected] > > > > > 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 > > > > > [email protected] > > > > > To unsubscribe please visit http://listserver.u2ug.org/ > ><http://listserver.u2ug.org/> > > > > > ------- > > > > > u2-users mailing list > > > > > [email protected] > > > > > To unsubscribe please visit http://listserver.u2ug.org/ > ><http://listserver.u2ug.org/> > > > >------- > > > >u2-users mailing list > > > >[email protected] > > > >To unsubscribe please visit http://listserver.u2ug.org/ > ><http://listserver.u2ug.org/> > >------- > >u2-users mailing list > >[email protected] > >To unsubscribe please visit http://listserver.u2ug.org/ > > > > > >-- > >No virus found in this incoming message. > >Checked by AVG Anti-Virus. > >Version: 7.0.344 / Virus Database: 267.11.13/126 - Release Date: 09/10/05 > > > > > > > > > >-- > >No virus found in this incoming message. > >Checked by AVG Anti-Virus. > >Version: 7.0.344 / Virus Database: 267.11.13/126 - Release Date: 09/10/05 > > Regards, > > Bruce Nichol > Talon Computer Services > ALBURY NSW 2640 > Australia > > http://www.taloncs.com.au > > Tel: +61 (0)411149636 > Fax: +61 (0)260232119 > > If it ain't broke, fix it till it is! > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.344 / Virus Database: 267.11.13/126 - Release Date: 09/10/05 > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
