Why not define a vdisk for storing the variables? Definitely faster than
the real thing.
Steve G
Kris Buelens <[EMAIL PROTECTED]>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
01/12/2007 11:38 AM
Please respond to The IBM z/VM Operating System
To: IBMVM@LISTSERV.UARK.EDU
cc:
Subject: Re: Rexx performance question
Using a file to store the variables a while, uggghhh...
File I/O remains terribly slow compared to memory access, even though you
might save some CPU (I don't know if you will save) the result may be code
than takes longer to complete in elapsed time.
The fact that EXECIO is faster than PIPE to write files is that one often
sees execs that every now and then write to a file. If you do that with
PIPE, the file is closed after each write request; with EXECIO, the file
is only closed when you explicitly ask for it.
Again, the general rule is: do as much as possible in a single call, to
PIPE, to XEDIt, to ....
2007/1/12, [EMAIL PROTECTED] < [EMAIL PROTECTED]>:
>From my testing, PIPES incur quite a bit of overhead when starting up.
So, optimising means doing as much as possible within a PIPE to amortise
that overhead over as much work as possible, and therefore using as few
PIPE instances as possible.
You could write the variables to a temporary disk file as well. But use
EXECIO instead of PIPES to write the file, it uses less resources for
small files.
-----Original Message-----
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU ] On
Behalf Of Peter Rothman
Sent: January 12, 2007 10:55
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Rexx performance question
Tested that - also much slower than GLOBALV.
Kris Buelens
<[EMAIL PROTECTED]
il.com>
To
Sent by: The IBM IBMVM@LISTSERV.UARK.EDU
z/VM Operating
cc
System
<[EMAIL PROTECTED]
Subject
ARK.EDU> Re: Rexx performance question
01/12/2007 10:23
AM
Please respond to
The IBM z/VM
Operating System
<[EMAIL PROTECTED]
ARK.EDU>
Have you tried this too?
PIPE LITERAL VAR1 VAR2 VAR3 ...| SPLIT |VARFETCH 1 DIRECT
TOLOAD|VARLOAD
DIRECT
Note: the "DIRECT" tells not to try to resolve compound symbols, this
also
means one must pass the variable names in uppercase (and stem suffixes
in
the exact case).
--
Kris Buelens,
IBM Belgium, VM customer support
2007/1/12, Peter Rothman <[EMAIL PROTECTED]>:
We have an old REXX exec that I had to modify.
This is a rather simplistic description but it consists of 2 parts - 1
to
set up the environment(variables) and 2 to use the variables setup in
1.
Bottom I had problems modifying it so I re-wrote it.
The original used GLOBALV extensively - part 1 would do PUTs and part
2
would do GETs.
Besides a lot of 'steam lining' I thought I would be 'clever' and
changed
the GLOBALVs to 'PIPE var VarName 1 | var VarName'.
However the new exec ran much slower than the old.
I then did a test to only compare GLOBALV PUT/GET to setting and
retrieving
the variable with PIPE var stage.
The pipe stage was much slower.
I thought the pipe logic would be better - obviously mistaken.
Any comments - any other method I could have used that is perhaps
faster
than GLOBALV?
Thanks
Peter
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review retransmission dissemination or other use of or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient or delegate is strictly
prohibited. If you received this in error please contact the sender and
delete the material from any computer. The integrity and security of this
message cannot by guaranteed on the Internet. The Sender accepts no
liability for the content of this e-mail or for the consequences of any
actions taken on basis of the information provided. The recipient should
check this e-mail and any attachments for the presence of viruses. The
sender accepts no liability for any damage caused by any virus transmitted
by this e-mail. This disclaimer is the property of the TTC and must not
be altered or circumvented in any manner.
--
Kris Buelens,
IBM Belgium, VM customer support
