I recently heard that there are plans to use isaexec to wrap ksh93. I think this is an incredibly bad idea. Especially given the microoptimizations that have been done lately to make ksh93 faster (e.g. the MMU page size adjustment.)
The reason for this is that I understand that someday ksh93 will replace the default shell. I agree that having a POSIX shell be the default will be a good thing for the system, and I look forward to the day with ksh93 can fulfill this role. What concerns me, is that the extra time (2 milliseconds was a rough measurement done in one case) it takes to spawn a shell is going to have a negative impact on overall system performance if this becomes the default shell. The shell is forked/execed a _lot_. Consider builds of Solaris, where "make" spends almost all of its time execing the shell. Consider large interactive servers like Sun Ray servers, or login servers like shared compute farms. Consider system startup. All of these things hit the shell rather quite a bit. And as a result, will be penalized by the cumulative effect of any startup penalty. The folks who stand to gain from an isaexec wrap of the shell are people who want to use the default shell to parse humongous amounts of data. (>2GB data). I have my personal doubts that this is ever a good idea, but there are evidentally some sites that use ksh-clones to parse such large data sets. I consider that those are an edge case, and not likely to be the "typical" users of the default shell. I don't think it is fair to penalize every shell invocation to service the needs of such users. I do think it may be reasonable to ship a 64-bit ksh93, e.g. in /usr/bin/sparcv9/ksh93 or somesuch, which can then either be hardlinked into /usr/bin or hardcoded into those scripts that need such large data, at the sites where it is necessary. So I'm not saying we shouldn't ship a 64-bit ksh93, I'm just saying that we shouldn't wrap ksh93 with isaexec. Anyway, I wanted to raise the objection, in public, so that is recorded. I trust the ARCs will do the right thing as making sure that it is at least considered before making any decision one way or the other. Thanks! -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191
