Steve vainly tries to deflect deserved MI criticism:
 
> Stan Sieler ([log in to unmask]) wrote:
> :    :fetch cicat.pub.sys             (a file of 13456 sectors)
...
> : that's 50% slower!       (Times on a 3000/968 with 128MB)
>
> : Ok, so you *DO NOT WANT TO EVER LEAVE A MI-BASED TOOL RUNNING ALL DAY*,
> : well...hardly ever :)      (MI-based tools have their place, certainly!)
>
> Try your test on a Native Mode file type. Bet you can't get
> any appreciable difference.
 
The last time I looked, a file like:
   ACCOUNT=  SYS         GROUP=  PUB
 
   FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
                     SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
 
   CICAT              80B  FA       42903      42903  16    13456  1 29
 
*IS* a "Native Mode file type".
 
Luckily for Steve, no wager was actually mentioned.  :(
(I could have used that new memory board for our 3000/968)
 
As usual, I chose my examples carefully for reproducability (well, you
might not have "fetch"/KLONDIKE, but you can simulate the effects via
Debug's FVA command), and applicability (e.g., reading an ordinary file)
via an HP-provided & supported utility program that many shops use.
(Yes, it's often not appropriate to use FCOPY...but people still use it.)
 
I deliberately did not choose to read a CM KSAM file, an RIO file, or
a pre-5.0 MSG file ... which are disk files managed by CM code.  (CIR files
pre 5.0 were managed by CM code too, but since that was MSG file code, I
assume (without checking) that they are now managed by NM code.)
Why?  I knew that they tend to fare even worse when the MI is turned on.
 
I generally remember to point out that the MI impact seems to be
significantly worse for CM programs ... which includes FCOPY.
 
However, here's a completely NM test (as well as any program can claim
to be completely NM, given that various parts of MPE are in CM):
 
   Program: REP.PUB.LPSTOOLS  ... a high performance, NM copy program...
                                  reads data via MR NOBUF reads.
 
   Task:    read CICAT.PUB.SYS (which has been frozen into memory)
            and copy it into a new flat file (purging the prior one)
 
   Major Intrinsics used:
        FOPEN, FCLOSE (purge), FCLOSE (save), FREADDIR, FWRITEDIR
 
   Timings:
                        CPU         Elapsed   (in milliseconds)
 
        no MI           493           527
                        494           547
 
        MI              522           567
                        523           557
 
   MI slowdown:          5.8%          5.7%  (using best times from each case)
 
(I ran the tests 16 times for each case, and reported the best two times
for each.  The no-MI tests varied very little.  The MI tests varied more.)
 
Please note:
   During this period the MI-enabler (GLANCEXL) was *not* doing any work.
In other words, if you are actively collecting data and
logging it, that will incur a performance penalty above and beyond the
simple "is MI on" overhead ... which we've now seen ranges from an
easily demonstratable, non-controvertible 5.7% up to 50%.  BTW, I've seen
worse percentages in the past (up to 70% overhead for extremely CM intensive
applications), but I quote them reluctantly as I don't think they are
representative of the average MI impact.
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html