|
> From: rob@xxxxxxxxx > > As I said before, a dyed-in-the-wool traditionalist got better performance > out of his SQL (he decided that it wasn't fast enough to justify changing > his programming paradigm). I don't know who this person is, but I've just run a test for the fun of it. I realize this test is blisteringly unscientific, but the results indicate that perhaps the hype might not match the reality. I have a file with 800,000+ records, each with a 10-character key with a different unique number (yeah, I know, numeric values in alpha field, but hey, I just whipped it together). I then took the following code: c for x = 1 to count c eval mykey = %char(x) c mykey chain j4pp1r c endfor - and - c for x = 1 to count c eval mykey = %char(count) c/EXEC SQL declare c cursor for select * from j4pp1 where key1 = :mykey c/END-EXEC c/EXEC SQL open c c/END-EXEC c/EXEC SQL fetch from c into :j4pp1 c/END-EXEC c/EXEC SQL close c c/END-EXEC c enddo I compiled the two, and then showed the results. I had to crank up the native I/O to 100,000 iterations to get a measurable difference, while the SQL version only required 10,000. Results: Start End Count Native I/O: 193459 193509 100000 SQLRPGLE: 194230 194241 10000 To the naked eye, in this very unscientific test, native I/O performed roughly 10,000 chains per second, while SQL scored about 900 fetches per second. This is an order of magnitude. This was with no optimization, right out of the box. I later optimized both programs, and the native I/O went down to seven seconds, while the SQL program, with COMMIT(*NONE) and a CHGPGM OPTIMIZE(*YES) dropped to ten seconds (for one tenth the records of the native I/O). So it seems optimization is even more effective for native I/O. I may have screwed up something here. Feel free to point out any issues. But this is the sort of test I think the new IAAI site is going to be very useful for. And those who are interested should definitely stop by the website. http://forums.plutabrothers.com/IAAI Joe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.