> From: "Brian T. Wightman" <wig...@so...>
>
> In message <960...@ca...>,
> Larry W. Virden, x2487 wrote:
> [- snip -]
> > HOWEVER - if Modules is seen as not being solid, as having weak points or
> > cause an increase in user problems, then you lose big time...
>
> For example, one of my "power users" that was helping to evaluate
> modules complained that startup time was too slow. He does a lot of
> parallel work, and the time needed to start an rsh, including all of
> the modules he uses, was obnoxious. A way to cache your environment
> would definitely help to address this problem.
At one time I did some extensive testing in this area. The result is
that I now use the Korn shell. What I found is that the way the
shell handles variables and paths is crucial to Modules performance.
The C-shell stinks when it comes to variables. It is rather trivial to
do a test, something like:
time modulecmd csh load xyz
will show how much time is really spent executing Modules. The remainder
is consumed by your shell in the eval.
I originally did this testing in order to optimize my modulecmd build.
I tried various combinations of static and dynamic linking. They were
inconclusive because modulecmd runs so fast.
Note: obviously one can write a modulefile that performs poorly.
I didn't :-)
-- richard
|