🚀 go-pugleaf

On 27 Feb 90 15:10:38 GMT, koren@hpfelg.HP.COM (Steve Koren) said:

Steve> Also, try giving it boatloads of stack.

Deven> I hate this approach.  Stack space can eat resources FAST.  Be
Deven> dynamic, dude.  Put *pointers* on your stack, and AllocMem.
Deven> Much nicer.  Less likely to crash, too...

Steve> SKsh already does dynamically allocate everything of any
Steve> significant size (such as tree parse nodes, etc), and passes
Steve> only a few pointers around between functions.  However,
Steve> recursion can become quite deep, especially in the case of
Steve> recursively called aliases or shell functions.  Some functions
Steve> declare quite a few automatic variables, and it is not
Steve> practical to allocate 4-byte variables dynamically; this would
Steve> kill the performance.

If you're allocating a BLOCK of variables, it might work out...

Steve> I do suspect that SKsh will run with less stack than I
Steve> recommend.  However, there is one point which is a little
Steve> unclear to me.  In AmigaDos, when you run another program
Steve> (*not* in the background) from yours, the second program runs
Steve> using the same process as the parent.  Does this mean that it
Steve> uses the same stack space, as well?  I'm not sure.  I can't
Steve> find that documented anywhere, so I always recommend more stack
Steve> than should be necessary.  Feel free to try less; if it works
Steve> for you, great.

Yes.  If it will run in the same process space, it will use the same
stack.  The thing is, the memory used really builds up.  I don't know
what all SKsh is keeping in memory, but It uses a LOT of memory.  When
I exit an instance of SKsh, it usually frees about 120-150K of memory,
and that's with the 70K executable RESIDENT.  I don't consider such
excessive use of resources to be justified, so I have switched back to
using AShell.  There are several other major reasons I stopped using
SKsh -- it is EXTREMELY slow, and it also takes a LOT of memory, and
it doesn't give useful error messages -- only cryptic numbers.
Granted, I haven't tried SKsh 1.3, but it seems unlike that it
improves on the stack, memory and speed problems.

Otherwise, it's a nice shell.  Merely unusable.  (on the systems I use.)

Steve> PS - I did some emperical tests, and Lattice's malloc() is
Steve> significantly faster than AllocMem() (in addition to being
Steve> standard).  It only matters if you do alot of dynamic
Steve> allocation, which SKsh does.

How fast is "significantly" faster?

Deven
-- 
Deven T. Corzine        Internet:  deven@rpi.edu, shadow@pawl.rpi.edu
Snail:  2151 12th St. Apt. 4, Troy, NY 12180   Phone:  (518) 274-0327
Bitnet:  deven@rpitsmts, userfxb6@rpitsmts     UUCP:  uunet!rpi!deven
Simple things should be simple and complex things should be possible.