[...]
> > To get around the problem
> > pmap: cannot examine 5608: address space is
> changing
> >
> > and get a closer look, try stopping the process
> first:
> >
> > pstop 5608
> >
> > and then running pmap or whatever to inspect it,
> and finally running
> >
> > prun 5608
> >
> > to let it run again.
>
> Why is pmap not doing this?
I don't know. I (a) don't work for Sun, and (b) only run
OpenSolaris under VirtualBox on an Intel Mac Mini (my other
systems are SPARC and running Solaris 9, and Solaris SXCE snv_97,
respectively). So just starting OpenSolaris under VirtualBox uses
about all the time I'm willing to spend getting my answer right
on anything but the most interesting problems. I would _guess_ that
either using the -F option might also help
-F Force. Grabs the target process even if
another process has control.
or else that there's a bug in (or affecting) pmap. I suggested
pstop/prun simply as the first thing I could think of to work
around the problem.
> > I suspect the shell script being run is the real
> problem; not too many
> > well-written shell scripts should grow to such
> monster size.
>
> We called upon the author to explain: He said the
> script caches many
> data in memory (arrays) during execution and the 19G
> memory peak usage
> matches the working set of the input data.
Ok. Sometimes, esp. if it would otherwise run very slowly,
that can make sense.
> We're still verifying the output because the script
> finished in four
> hours while the legacy perl version of the script
> used to run a whole
> weekend.
> This is suspicious and too good to be true.
Maybe, maybe not. If the rewrite also improved the algorithm
or implementation, that's entirely possible. Also, a lot of perl
scripts run more external programs than they really ought to.
Recent ksh93 has a lot of built-in commands that used to require
running external programs. So for any of various reasons, such
an improvement, although suspicious, doesn't seem at all impossible
to me. (It also leaves me thinking that perhaps with enough effort,
further improvements might be possible.)
Note: I'm not necessarily saying that recent ksh93 is faster than
perl. Both can be fast or slow depending on how the script is
written; probably neither will give as much help to optimize out
slow things the programmer did as would some other languages.
It used to be that perl was often faster than shell scripts, perhaps
only slower if the longer startup time for perl was an issue. But
recent ksh93 is probably at least capable of being quite close
(or _maybe_ even a bit faster), so simply assuming that one
is faster than the other is probably more wrong now than it
ever was.
I think I've read things suggesting that the ksh93 developers
want to make it competitive with perl in both speed and
at least commonly used functionality. Although even if it
were there today (and on functionality, I don't think it is really),
it would be a long time before there was anything like perl's CPAN.
Nevertheless, where it's good enough, I like ksh93 better myself.
I learned C and awk and sed way back before perl even existed, so
perl looks to me like a stew with random bits of everything
mixed in. It gives me a headache, and I have to have a manual
open the whole time I write something in it. Borrowing stuff
from everywhere may look natural to someone like Larry Wall
(perl creator) who started as a linguist, but to me, usually
more comfortable with predictable computers than unpredictable
people, I'd rather use a language where I can remember a few rules
rather than a lot of details.
--
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
