Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!ENGVAX.SCG.HAC.COM!KVC
From: KVC@ENGVAX.SCG.HAC.COM.UUCP
Newsgroups: comp.os.vms
Subject: Re: faster VMS spawn
Message-ID: <8704220233.AA01827@ucbvax.Berkeley.EDU>
Date: Tue, 21-Apr-87 13:46:00 EST
Article-I.D.: ucbvax.8704220233.AA01827
Posted: Tue Apr 21 13:46:00 1987
Date-Received: Thu, 23-Apr-87 02:43:06 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 42

>                                  If we can't find any better way we are
> going to be forced to link all of our object code (currently about 13
> Megabytes of object code constituting 66 separate executables) into one
> gigantic executable (gag!).

PLEASE DO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I've got no qualms with running a large executable image.  That's what virtual
memory and cheap physical memory is for.  Why force the system to do something
it does inefficiently (create processes -- especially with SPAWN!  At
least you could use CREPRC!) when you can let VMS handle the job in the
manner for which it was designed?

Forgive me if my tone's a little harsh, but I've spent years putting up with a
software system, Project/2 from PSDI, with just this problem.  These people
(PSDI) run scores of separate little images in subprocesses.  It's really
exciting to watch the system thrash around as it
creates/deletes/context-switches all these processes.  It even looks like P2
tries to cache it's processes (I'm not certain of this, though) and it's
still a dog.

PSDI once explained that they use multiple images because it makes development
easier -- they don't have to wait around to relink everything on a build.
Seems like a pretty lame excuse to me, I suspect they've heard of sharable
images.   This explanation is a few years old, maybe they have a more
legitimate excuse.

Using VMS facilities (e.g. sharable images) and reasonable development tools,
the MATHLIB project I'm associated with has never had a problem maintaining a
large software system with several large executables.  Most MATHLIB executables
require in excess of 2 to 3 Mb when they start up.  Performance is excellent.
VMS makes it a snap to produce a large system while taking a modular approach
to the design.

Maybe you need to step back and reassess your application.  One 13 Mb image may
indeed be excessive, but is it any more so that 66 separate little ones?
If it's a big system, expect some big images to come out of it.  Be reasonable,
use separate images where appropriate, but don't hesitate to make things big
when/if it makes sense! The performance gains you realize may be considerable!

        /Kevin Carosso                        kvc@engvax.scg.hac.com
         Hughes Aircraft Co.