Well, only testing would reveal that. Anything else is just speculation that "it's better now". My last testing of GOTO's revealed they are still slower than GOSUB's and this was last year.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Keith W. Roberts Sent: Wednesday, October 05, 2005 09:42 To: [email protected] Subject: RE: [U2] Fw: More U2 programming hints ----Original Message---- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen E. Elwood Sent: Tuesday, October 04, 2005 2:45 PM To: [email protected] 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. Yes, well that *was* back in '88. :) Actually, I've no idea what UV does; there are many things which were implemented differently from Pr1me INFORMATION, or not at all. But IIRC, the issue above was addressed by pre-fetching the next group while processing the current one, so that processing and I/O overlap. With the right tuning, it would be significantly faster than processing after an external SELECT. -Keith ------- 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/
