Xref: utzoo comp.unix.questions:6970 comp.unix.wizards:8393
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: KSH portability
Message-ID: <52952@sun.uucp>
Date: 12 May 88 01:18:54 GMT
References: <295@cmtl01.UUCP> <12142@tut.cis.ohio-state.edu> <631@vsi.UUCP> <13059@tut.cis.ohio-state.edu>
Sender: news@sun.uucp
Lines: 23

> I think Korn placed a big emphasis on ksh's performance.  I would gladly
> give up a bit of portability to gain performance,  Korn may feel the same.
> I would rather have portability and high performance but I'll give up
> portability if that was necessary.  To me, it is more important to make ksh
> users happy than ksh hackers.

People often toss portability in favor of "performance" when they really don't
gain much performance by doing so.  I have yet to see any evidence that on a
modern machine, at least, the SIGSEGV trick for growing a process's data space
on demand buys you anything.  (I tried

	echo `cat *.c`

in the Bourne shell source directory, both with the vanilla S5R2 Bourne shell
and one modified to explicity test whether the data segment had to be grown, on
a 3B2/400; the performance was the same for both shells.)

Given that I have worked on a variety of machines, with different standard I/O
implementations, different byte orders, different sizes for pointers and
integers, different levels of support for catching SIGSEGV and returning from
the signal handler, etc., *I'd* gladly give up a bit of performance to gain
portability.  You can't make "ksh" users very happy if "ksh" doesn't work at
all....