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/
