Xref: utzoo comp.unix.questions:11063 comp.os.vms:11095
Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!cornell!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.unix.questions,comp.os.vms
Subject: Re: Do OS's slow down with age?  (was: DDJ article / UNIX vs BS/2)
Message-ID: <7172@batcomputer.tn.cornell.edu>
Date: 12 Jan 89 18:48:14 GMT
References: <209@imspw6.UUCP> <12872@steinmetz.ge.com> <370@siswat.UUCP> <1472@cps3xx.UUCP> <12938@steinmetz.ge.com>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 41

In article <12938@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>In article <1472@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes:
>|   There is a lot of process creation overhead in VMS.  On the other
>| hand, you don't need to create a process every time you do anything
>| (as UNIX does).  In fact, most "basic" users (edit/compile/link) will
>| log in and use only their one process (or maybe two, if they have a
>| background editing process).
>
>  I talked to a few VAX support people again, and they agree about
>process creation. Unfortunately VMS does what's called "image
>activation" which still results in reading a program from disk,
>establishing an environment (in the VMS sense) and all the things UNIX
>calls a subprocess, except accounting. This happens when you start the
>editor, compiler, linker, run the program, etc. It still isn't cheap in
>terms of system resources.

The image activation overhead is tiny compared to the process creation
overhead.  Image activation is like process creation on a UN*X system--
cheap and fast.  Process creation, on the other hand, is miserably
expensive under VMS.

I tend to think that the process creation overhead is a bigger problem
than previous posters have admitted.  Many of the attempts by DEC (and
third parties) to improve the VMS user interface and functionality use
subprocesses.  Send/edit in mail spawns a subprocess (or calls one of
the callable editors, which is cheaper).  The debugger now tries to
spawn a subprocess (in the latest release).  MMS spawns a subprocess.
Subprocesses are being used more and more, and, on a loaded system, it 
really shows.  An 8600 makes a great one or two-user system, but put
any more on it, and the process creation overhead starts to get very
annoying.

I expect this problem to get worse as DEC implements more advanced user
interfaces under VMS.  DEC will probably be at least one step behind
companies like Apollo in user interface design for the foreseeable
future, and I think the process creation overhead is a major reason
for this.  (I could also go on about DECNET network overhead, but that's
a bit off the topic.)

-Dan Riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet)
-Wilson Lab, Cornell U.