The 1.5j version of LSVSFILE contains some enhancements that will speed up
GET commands by a factor of 2-4 (average) and PUTs by about 60%. The main
differences with respect to the 1.5i version are a) the use of LSVFILER
instead of EXECIO to read FILELISTs and b) an important design improvement
that consists in reading the filelist up to three consecutive times to search
a filelist entry (yes, that's an *improvement*, you'll see :-).
LSVFILER has been extended to allow FIND and LOCATE options (much like EXECIO,
but without delimiters), two interesting NONUM and NODATA options to avoid
getting stacked/stemmed line numbers (or line data) when you don't need them,
and, much more important, an ALL option that returns all the lines satisfying
the target search, not only the first one (compare that with EXECIO... :-).
As I said, LSVSFILE searchs each filelist for a matching fn ft entry up to
three times: the first one it searchs for fn ft directly; then it searchs for
generic fileids matching fn ft; and finally, it searchs for all 'true'
filelist entries (ie, '/F' flagged) and enters recursion if needed. To avoid
the overhead associated with reading a file thrice, a new set of options has
been developed to allow keeping in-storage copies of a file upon request. This
means probably a bit more of paging but reduces substatially I/O and wall
clock time.
Note that as filelists become larger and more nested the new LSVFILER gain
becomes also percentually greater, while it is neglible for flat filelist
spaces.
-----> Those of you who hate statistics can stop reading here <-----
The following figures were obtained via #CP Q T + GET|PUT + #CP Q T by
subtraction. The following LSVSFILE versions were benchamrked: 1.5i, 1.5j (ie
1.5i + LSVFILER), 1.5j+ (1.5j + read the file thrice ---> avoid having to
filter with rexx), 1.5j++ (1.5j+ with the in-storage file option).
Scenario:
* LISTSERV FILELIST is 158 lines long
* INTERN FILELIST is a child of LISTSERV. It appears at line 235 and there are
64 filelists before it on LISTSERV FILELIST. One of these has 1140 lines.
INTERN itself has 1083 lines.
* M FILELIST is also a child of LISTSERV. It has 1140 lines, and appears at
line 132 in it (61 filelists before).
* SERVINFO FILELIST is a child of INTERN. To make things worse, I've put it
just at the bottom of intern, ie at line 1083. There are no other childs of
INTERN. Servinfo has 249 lines.
* VMFSTK HELPCMS is a 67 lines file located at the bottom of M FILELIST.
* TEST TEST is a test file. It's the first file on LISTSERV FILELIST, line 39.
* MAILBOOK INFO is the last line of SERVINFO filelist.
* NETMONTH 1986* is a generic entry on SERVINFO (line 60+). I've put NETMONTH
1986NOV (800 lines).
* CON MODS is a 55 lines file declared in INTERN FILELIST, line 178.
Here are the numbers (vtime/ttime):
1.5i 1.5j 1.5j+ 1.5j++
------- ------- ------- -------
GET VMFSTK HELPCMS 3.20/4.35 2.91/3.63 1.23/1.96 1.20/1.90
GET VMFSTK HELPCMS M 2.24/2.85 2.05/2.69 0.81/1.46 0.81/1.46
GET TEST TEST ›LISTSERV! 0.55/1.40 0.50/1.10 0.50/1.10 0.50/1.10
GET MAILBOOK INFO look!! ---> 7.46/8.28 6.70/7.05 2.09/2.86 1.98/2.66
GET MAILBOOK INFO SERVINFO 0.90/1.80 0.91/1.83 0.66/1.32 0.86/1.77
PUT NETMONTH 1986NOV SERVINFO 5.29/6.46 4.84/6.11 2.86/4.07 2.82/4.02
PUT COM MODS INTERN 2.96/3.72 2.15/3.01 1.83/2.72 1.85/2.75
Notes:
1.- GET MAILBOOK INFO is the most improved. It's also the most nested.
2.- I'm a little surprised of the 1.5j++ to 1.5j+ comparison for GET MAILBOOK
INFO SERVINFO. Perhaps that's the extra overhead generated by reading
1000+ lines into storage. Anyway, clock time is much improved in all
cases, even if there is a slight increment of cpu time for 1.5j++.
3.- I've not had time to test PUTs without the filelist parameter.
Jose Maria
|
