From: ERIC@SEARN.BITNET (Eric Thomas)
Newsgroups: bit.listserv.lstsrv-l
Subject: Re: Compilation of LISTSERV
Date: 5 Sep 92 00:29:15 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
              4 Sep 1992 18:07:23 GMT from "Forum on LISTSERV release 1.7"
              <LSTSRV-L@SEARN>

>SHOW BITEARN command
>                               Compiled        Regular
>CPU sec.                           .15            .62
>Paging                              61             16
>WS (observed maximum IND USER)     225            174

LSVSHOW was not  EXECLOADed by the version used for  this test, otherwise
the difference in CPU time would be  irrelevant due to not having much to
do for this command;  here what you are seeing is the time  to load a big
REXX  source into  memory one  line  at a  time  vs the  larger LRECL  of
compiled  files.  The interpreter  wins  on  paging  and WS  because  the
compiled  version is  usually about  5  times larger.  I don't  recommend
compiling  LSVSHOW on  storage  constrained systems  unless  you use  the
command very often.

>NODESGEN command
>
>CPU                              39.37         113.62
>Paging                             127             82
>WS                                 377            326

That one  is now in  PREXX, although  some of the  post-processing (PEERS
DISTSUM, REFRESH, etc) is still in REXX  and amounts to half of the total
CPU time.
-------------------------------------------------------------------------
Date:         Sat, 5 Sep 1992 02:03:18 +0000
From:         Revised List Processor (1.7d) <LISTSERV@LEPICS.BITNET>
Subject:      Output of your job "ERIC"
To:           ERIC@LEPICS.BITNET

> nodesgen
Nodes tables generation process started - be patient...
(...)
Nodes tables generation completed successfully.

Summary of resource utilization
-------------------------------
 CPU time:        2.463 sec                Device I/O:   530
 Overhead CPU:    0.325 sec                Paging I/O:     0
 CPU model:        3090                    DASD model:  3380
-------------------------------------------------------------------------
Note: the figures  cannot be compared directly because the  CPU's are not
the same and  the 1.7 code has more  work to do due to  new functions and
the data conversion required for the new format ':links' tags.

Compiling LSVBITGN  won't help much with  1.7d, it is LSVPRSUM  that eats
most of  the 1.5  sec burnt  up by REXX  code. But  then who  cares about
fractions of seconds a few times a month?

>DIST2 job (4 local, 1 remote recipient)
>
>CPU                                .40           1.61
>Paging                              59              7
>WS                                 269            216

Compiling LSVDIST2 helps  a lot, because of all the  nested loops. If you
are going to compile  one EXEC, this is the one to  choose. The second is
LSVXMAIL. Other good choices are LSVCKPRV, LSVBLC and LSVMAIL (for 1.7d).
If you compile *any* EXEC, please  also compile LSVPROF. This is the EXEC
that sets  the "compiled" flag  you can  query with the  RELEASE command.
Compiling LSVPROF won't  save you any time, but it's  only 120 lines long
and won't cost you much memory.

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU