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....