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:[EMAIL PROTECTED] 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

Reply via email to