× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Expensive op codes
  • From: "Peter Dow" <pcdow@xxxxxxxxx>
  • Date: Sat, 16 Oct 1999 18:31:11 -0700

Thanks Dave! That's fascinating. I would've expected that since READE and
READ/compare are logically the same thing, the compiler would produce the
fastest possible code.  I wonder if there's any difference if the physical
file is not in key sequence.  And you're right - I'll be using the
READ/compare now too.

If you still have the data and program sitting around, what happens to the
times if you slip in a date operation in the loop?  Then a MULT or DIV?

Thanks again. I wish I had a dedicated box to try this stuff on!

Peter Dow
Dow Software Services, Inc.
909 425-0194 voice/fax



----- Original Message -----
From: Dave Murvin <davem@drme.com>
To: <RPG400-L@midrange.com>
Sent: Saturday, October 16, 1999 2:55 PM
Subject: Re: Expensive op codes


> Vanja Jovic wrote:
>
> >         I wouldn't speculate on cost in terms of processor time, as I
think
> > that is irrelevant in today's real world. However, READ then IF (or DO
> > WHILE key = constant) can be way faster than READE, again not because of
> > the processor, but because of blocking. In this case, it's an I/O issue,
> > and with today's state of hardware it can not be neglected.
>
> I have been doing some testing on record blocking and reading of large
files.
> Some of these tests may have been unscientific, but I think they point the
way to
> go.
>
> All tests were run in batch on a dedicated S10.  Test jobs were the only
> application running.
> File being read is a keyed logical with the physical file in the same
sequence as
> the key.
> Number of records in file is 1,027,600 with record length of  191
>
> Both test runs used OVRDBF FILE(ECLL02) SEQONLY(*YES 341)
> Both test runs read the entire file by key.  Program 1 used READE, program
2 used
> READ and compare.
>
> Program 1 elapsed time was 33 minutes 38 seconds.
> Program 2 elapsed time was 12 minutes 38 seconds.
>
> I think I will be using the READ/Compare model versus the READE model
whenever
> possible when I need to read by key.
>
> By the way, reading the non keyed physical file with the same OVRDBF only
took 1
> minute 22 seconds.
>
> Program 1:
>
>  FECLL02  IF  E           K        DISK
>   *
>  C                     READ ECLL02                   90
>  C                     MOVE LORD      ECLKEY  60
>  C           TOP       TAG
>  C           *IN90     DOWEQ*OFF
>  C           ECLKEY    READEECLL02                   90
>  C                     ENDDO
>   *
>  C           LORD      SETGTECLL02               LR
>  C           *INLR     IFNE *ON
>  C                     READ ECLL02                   90
>  C                     MOVE LORD      ECLKEY
>  C                     MOVE *OFF      *IN90
>  C                     GOTO TOP
>  C                     ENDIF
>
> Program 2:
> FECLL02  IF  E           K        DISK
>  *
> C                     READ ECLL02                   90
> C                     MOVE LORD      ECLKEY  60
> C           TOP       TAG
> C           ECLKEY    DOWEQLORD
> C           *IN90     ANDEQ*OFF
> C                     READ ECLL02                   90
> C                     ENDDO
>  *
> C           LORD      SETGTECLL02               LR
> C           *INLR     IFNE *ON
> C                     READ ECLL02                   90
> C                     MOVE LORD      ECLKEY
> C                     MOVE *OFF      *IN90
> C                     GOTO TOP
> C                     ENDIF
>
> PS.  I don't normally use GOTOs and I try to use ILE/RPG whenever I can.
> --
> Dave Murvin
> DRM Enterprises, Inc.
> davem@drme.com
>
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---


__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.