Out of curiosity, I ran this as interpreted REXX and then as compiled
REXX.
The REXX compiler does not like SYSVAR so I just ran them both as batch
jobs and looked at the IEF032I message in JES SYSTEM MESSAGES:
Interpreted (Non-compiled )
IEF032I STEP/STEP010 /STOP
2018255.1024
CPU: 0 HR 00 MIN *13.10 *SEC SRB: 0 HR 00 MIN 00.00
SEC
Compiled
IEF032I STEP/GO /STOP
2018255.1023
CPU: 0 HR 00 MIN *00.25* SEC SRB: 0 HR 00 MIN 00.00
SEC
Very dramatic improvement - approx 50 times faster.
This was on a zPDT
The code I used:
/* REXX */
I = 0
DO 9999999
I = I + 1
END
EXIT 0
On Wed, 12 Sep 2018 at 06:55, David Crayford <[email protected]> wrote:
> We're running a 2965-N10 and your snippet took a gargantuan 19.33 CPU
> seconds on our machine. I was curious as to what it was doing to take up
> so much time so I profiled it.
> Astonishingly, it's spending most of the time moving data! The REXX
> implementation on z/OS predates modern scripting language design which
> generally compile to bytecode for processing in a VM.
>
> Address Module AM S/P AS ASID Percent of CPU Time * 10.00% ±1.7%
> *....1....2....3....4....5....6....7....8....9....*
> 0D5ABC50 - IRXINIT 31 P8 21.73 OOOOOOOOOOO
>
> > IXXRCN+0C4C 46F0 CC1C BCT R15,3100(,R12)
> > IXXRCN+0C50 D200 F000 3000 MVC 0(1,R15),0(R3)
>
> 0D5ABC56 - IRXINIT 31 P8 21.22 OOOOOOOOOOO
>
> > IXXRCN+0C50 D200 F000 3000 MVC 0(1,R15),0(R3)
> > IXXRCN+0C56 1B3B SR R3,R11
> > IXXRCN+0C58 1BFB SR R15,R11
> > IXXRCN+0C5A 1932 CR R3,R2
> Alternate Disassembly
> > IXXRCN+0C54 3000 LPER R0,R0
> > IXXRCN+0C56 1B3B SR R3,R11
> > IXXRCN+0C58 1BFB SR R15,R11
> > IXXRCN+0C5A 1932 CR R3,R2
>
> 0D5B1D46 - IRXINIT 31 P8 4.92 OO
>
> > IXXRIN+0432 1853 LR R5,R3
> > IXXRIN+0434 0E24 MVCL R2,R4
> > IXXRIN+0436 0620 BCTR R2,R0
> > IXXRIN+0438 952A 2000 CLI 0(R2),42
>
> On 12/09/2018 9:53 AM, Jackson, Rob wrote:
> > Hah, indeed it did. I was surprised too. I added in the redundant
> count in the first place simply because I assumed a simple loop might not
> cause even a hundredth of a second CPU usage. I was astonished, even
> knowing REXX is inherently a pig, albeit a generally pretty pig (yeah,
> yeah, Python is pretty too).
> >
> > We are on a baby machine, a 2965-Txx, so that accounts for some of it,
> but still, yes, REXX is indeed expensive.
> >
> > First Tennessee Bank
> > Mainframe Technical Support
> >
> > -----Original Message-----
> > From: IBM Mainframe Discussion List <[email protected]> On
> Behalf Of David Crayford
> > Sent: Tuesday, September 11, 2018 9:44 PM
> > To: [email protected]
> > Subject: Re: Co-posted: Rexx performance measures
> >
> > [External Email]
> >
> > Crikey! Did it really take REXX a whopping 7.7 CPU seconds to count to
> ten million?
> >
> >
> > On 12/09/2018 3:52 AM, Jackson, Rob wrote:
> >> Works for me just fine. Looping ten million times and incrementing a
> counter by one resulted in this:
> >>
> >> Bgn CPU: 68.66
> >> Bgn SRV: 2447864
> >> End CPU: 76.36
> >> End SRV: 2721588
> >>
> >> First Tennessee Bank
> >> Mainframe Technical Support
> >>
> >>
> >> -----Original Message-----
> >> From: IBM Mainframe Discussion List <[email protected]> On
> >> Behalf Of ITschak Mugzach
> >> Sent: Tuesday, September 11, 2018 3:36 PM
> >> To: [email protected]
> >> Subject: Co-posted: Rexx performance measures
> >>
> >> [External Email]
> >>
> >> I am trying to measure Rexx exec performance metrics. Elapse is easy
> >> Time('R') at start exec resets the counter and the second one reports
> the value. But how to measure CPU or service units? I tried SYSVAR('CPU')
> at beginning of exec and at end, thinking to do the calculation myself, but
> both returns the same value ... same behevior with SYSVAR('SYSSRV').
> >>
> >> I am a good developer, but i am not fooling my self I am SO good. what
> is the trick to return the service units consumed by the exec?
> >>
> >> ITschak
> >>
> >> --
> >> ITschak Mugzach
> >> *|** IronSphere Platform* *|* *Information Security Contiguous
> >> Monitoring for Legacy **| *
> >>
> >> ----------------------------------------------------------------------
> >> For IBM-MAIN subscribe / signoff / archive access instructions, send
> >> email to [email protected] with the message: INFO IBM-MAIN
> >> FIRST TENNESSEE
> >>
> >> Confidentiality notice:
> >> This e-mail message, including any attachments, may contain legally
> privileged and/or confidential information. If you are not the intended
> recipient(s), or the employee or agent responsible for delivery of this
> message to the intended recipient(s), you are hereby notified that any
> dissemination, distribution, or copying of this e-mail message is strictly
> prohibited. If you have received this message in error, please immediately
> notify the sender and delete this e-mail message from your computer.
> >>
> >>
> >> ----------------------------------------------------------------------
> >> For IBM-MAIN subscribe / signoff / archive access instructions, send
> >> email to [email protected] with the message: INFO IBM-MAIN
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] with the message: INFO IBM-MAIN
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
--
Mike Shorkend
[email protected]
www.shorkend.com
Tel: +972524208743
Fax: +97239772196
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
