Path: utzoo!attcan!uunet!ns-mx!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!hellgate.utah.edu!uplherc!giga!unislc!dgb
From: dgb@unislc.uucp (Douglas Barrett)
Newsgroups: comp.sys.next
Subject: Re: NeXT vs. Mac
Message-ID: <1990Oct29.003946.17250@unislc.uucp>
Date: 29 Oct 90 00:39:46 GMT
References: <9010201909.AA12905@mcs-server.gac.edu>
Organization: Unisys, SLC Utah
Lines: 55

From article <9010201909.AA12905@mcs-server.gac.edu>, by scott@NIC.GAC.EDU:
> aberno@questor.wimsey.bc.ca (Anthony Berno) writes:
>    The only thing I don't get is why applications take so long to launch on
>    the NeXT. Perhaps they are intrinsically bigger?
> 
> This is because of the amount of run-time initialization required . . .
> which I have a question about.  Would it be possible to initialize and

Well... no.  A unix executable file consists of 2 things.  text and
directives.  the text is of course the raw machine code.  before text
can run it needs addresses resolved.  almost all modern cpus will
accept a reletive addressing mode (ie no need to resolve *local*
addresses), so only nonlocal addresses need be resolved.  The amount
of work here depends intirely on the archetecture.  most use a vector
for system calls, these require little address patching.  Shared text
and libraries are really quite fast (the memory is already allocated and
initialized), there is just some region pointers to fix up.So the text
really requires little effort (*usually*).

the directives are a problem.  they instruct the loader how to
initialize static memory.  this includes zeroing bss and doing
the initialization.  this takes some time, but not all that much
(for most apps).  auto memory and stack require no initialization.

so the directives and resolution really are quite quick, and 
occur at an unpreempable priority.  so why does it take so long
to fire off a process on a UNIX system?

the real problem is all of the os overhead.  the process needs to
fill out a proc slot.  it needs its region table initialized to
point to enough memory to get the process started.  it needs a
u.  and if the file is not in memory just bringing it in takes
time.  and speaking of files, even after an app has started, it
is *very* common for it to begin by doing io, even *opening* a
file involves a lot of overhead and disc reads.  thus even after
a process has started it may lose several quanta doing disc io,
which to the user looks like the process has not started.  yes
running a complicated os (compared to ie a Mac) is complicated.

now once a process is unloaded its region table is no longer valid,
the memory having been given to some other user.  so there is no
way to "unload" a process and keep it runable.  the situation is
not hopeless though.  startup time can be reduced by firing off
a daemon to keep as many resources as practical.  for *many* apps
this makes a lot of sense.  if the process is idle for too long
it will be paged out (or swapped on some systems).  starting a
swapped process is not much faster than starting a process from
scratch.  its region table is no longer valid, and it may have
lost its buffers.  but once an app is unloaded it must lose its
memory.

------------------------------------------------------------------
Douglas Barrett                                 I speak for myself
Unix Systems Programmer
Unisys SLC Utah