Background information: as you might have heard, the REXX compiler has been recently added to the list of HESC programs, which basically means that academic sites on the "right" side of a US customs office will soon be able to get it free of charge. This in turn means most of BITNET may soon have the REXX compiler available, and may want to compile LISTSERV to save cycles. Unfortunately, a significant fraction of the 1.6e code (in terms of number of EXEC files) is not compilable; since these non-compilable EXEC's are the ones most frequently executed (LSVCMD, LSVDIST2, LSVXMAIL, LSV822IN) and burning most of the CPU time LISTSERV is using, there is very little to be expected from a compiled version of 1.6e. Since this was not precisely satisfactory, I took steps to make most of LISTSERV compilable in the next release. Unfortunately this means it will be a bit slower when interpreted, but not considerably so. Anyway, the potential savings for over 70% of the LISTSERV sites simply made it a non-issue - it just had to be done. So, I was waiting for the first LISTSERV sites to install the REXX compiler when I noticed, yesterday, that CERNVM already has it. I do not have a test LISTSERV account on that machine, so I could not make any "real life" test, but I did compile a few EXEC's and run some benchmarks. Since most of the LISTSERV code won't run outside the LISTSERV environment, I substituted "standalone" EXEC's of mine with a similar "profile" (read a file, do some processing, generate some terminal output). The results are, as I expected, very disappointing. The "purest" piece of REXX in LISTSERV, LSV822IN (does not issue any CMS command and takes around 1M instructions to complete) turned out to be a mere 3.4 times faster when compiled. This in itself would not be so bad if it were not by far the best improvement I have seen; most programs that do I/O (I/O really means intensive EXECCOMM-ing in this context, this data is acquired via LSVFILER, not EXECIO - the CPU time required for the actual I/O is negligible) are around 2.5, some as low as 1.7. Since your average backbone LISTSERV spends most of its time processing DISTRIBUTE jobs and the compiler won't speed up disk or spool I/O, I think it would be unwise to expect a CPU improvement in excess of a factor of 2. Now, what is so bad about cutting the CPU bill in half? Well, apart from the fact that this isn't the kind of performance one would expect from a "compiler", there is a price to be paid for the 1.7 to 3.4 savings in CPU time: the compiled code is around 4 times larger than the interpreted version. This means you won't need 400k for the EXECLOADed "core", but 1.6M; I will let you draw your own conclusions as to the consequences this will have on the working set of LISTSERV, and on the amount of disk I/O generated when a non-EXECLOADed file is called. It would be interesting to see whether the compiled version runs faster (in terms of wall-clock time, notwithstanding the impact on the other users) on a "small" machine with 16M of real memory or less and a strained paging subsystem. I guess for such sites the best will be to compile what really needs to be compiled, and leave the rest alone. Eric