I'm sure we can have this discussion off-ARC
size can be levereged when properly engineered
(properly == transparent to the user save space/time measurements)
a few years back we did a real world test on a handheld with
ksh+libshell.so+libcmd.so+libast.so+libcmd-main-stubs
where libcmd-main-stubs were all hard links to one main a.out for
all ast libcmd command and the disk footprint was smaller than
the equivalent set of /bin utilities, and, once the .so's were
pulled in by the first exec, ksh startup time was in the noise,
and set up to use the builtin libcmd commands directly enabled
the usual fork/exec-less speedups
in that off-ARC discussion we can resurrect real numbers
based on scripts you deem typical for embedded systems
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
On Fri, 30 May 2008 13:55:04 +0200 Joerg.Schilling at fokus.fraunhofer.de
(Joerg Schilling) wrote:
> Roland Mainz <roland.mainz at nrubsig.org> wrote:
> > > Did you thing about the fact that ksh93 is _really_ big and that people
> > > who
> > > like to use OpenSolaris in embedded environments probably cannot use
> > > ksh93 for
> > > this reason?
> >
> > Erm... the issue is the other way around - the use of builtin commands
> > enables ksh93 to work much faster and with less memory (since you can
> > avoid awk/sed/tr/etc. completely and even avoid temporary files for
> You would need to prove this on an embedded system. I am not convinced at all.
> If you run huge shell scripts like "configure", I would expect the ksh to be
> faster but for the scripts that Solaris uses for startup, things look much
> different.
