I'm pretty sure the internal select (method 2) selects just the next group at a time and feeds from that until it needs another. In this method you can get instant results, pretty much like doing a LIST. So this method would be good where output is being fed to the crt, and you might not want to process the whole file,
The external list (method one) selects all the records and stores them as a list of keys. During this selection process, most operating systems are going to stick the whole file into active memory as it becomes apparent to the O/S that the entire file is being processed sequentially. Therefore when the records are being accessed they are already in main memory instead of having to be read from disk and that is why it is faster. Probably :-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Stevenson, Charles Sent: Thursday, June 17, 2004 11:16 AM To: [EMAIL PROTECTED] Subject: [U2] relative speed of Retrieve SELECT vs Basic SELECT, LOOP READNEXT,READ. was: [UV] WHILE READNEXT id DO Please let me deflect this thread before it degenerates into a GOTO war. Which would you suppose is much faster: 1: T0=TIME() FOR I = 1 TO 100 EXECUTE 'SELECT VOC WITH TYPE = "V" COUNT.SUP' LOOP WHILE READNEXT ID NULL ;* GOSUB DO.STUFF REPEAT NEXT I T1 = TIME() CRT T1-T0 or 2: T0 = TIME() OPEN 'VOC' TO F ELSE STOP FOR I = 1 TO 100 SELECT F LOOP WHILE READNEXT ID READ REC FROM F, ID THEN IF REC[1,1]='V' THEN NULL ;* GOSUB DO.STUFF END END REPEAT T1 = TIME() CRT T1-T0 Notice how much less work #2 (seemingly) does: #1......................... #2.......................... spawns execution level 100x --- parses sentence 100x --- Opens data file 100x Opens data file once Opens dict 100x --- sequentially traverses 100x sequentially traverses file 100x -looks at every record 100x -gets id 1st, then record, 100x builds list of V-ids 100x --- Method 2 takes 2 or 3 times as longer to run than Method 1. It's not because VOC is a special file. I've tried it on other files, big and small. Note: SELECT F is a BASIC select, not Retrieve's (not the MV Query Language's) verb. It does not really select the file, it merely sets up for the subsequent READNEXTs to truly read the next key. So READNEXT ID;READ REC FROM F, ID involve going to the file 2x. Generally the group is still in memory when READ is requested. on a well-sized, well-behaved file several READNEXT-READ pairs will be acting on a group or groups loaded into memory only once. But is that where the inefficiency lies? Doing the READ subsequent to the READNEXT? HPUX 11i, uv 10.0.16. I'd love to hear an explanation &/or comparisons to UD. Chuck Stevenson ------- 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/
