fast subshell

fast subshell

[Ray Andrews]

So, now that I am awake to the usefulness of subshells in a function, 
I'm still exploring the implications on speed since a subshell sounds 
like it would be a lot of work.  However, using it to  control my old 
friend IFS, whereasI had previously done this:


     local IFS=$'\n' # Must split on newlines only.
     all_matches=( $( whence -mavS $@ ) )
     IFS=$OLD_IFS

... now trying:


(
     IFS=$'\n' # Must split on newlines only.
     all_matches=( $( whence -mavS $@ ) )
)

... and the interesting thing is that the former executes a stress test 
in ca. 290 mS, but the latter in ca. 250 mS.  The difference isn't 
significant in the real world, but it is hard to understand, it seems 
strange that the subshell would be faster. Is this possible?  If so, how 
should I understand it?  It seems as if a subshell is a rather 'lite' 
thing after all, in the above it seems to be hardly more than a scoping 
of IFS.

Re: fast subshell

[Bart Schaefer]

On Sun, Apr 1, 2018 at 8:59 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>     local IFS=$'\n' # Must split on newlines only.
>     all_matches=( $( whence -mavS $@ ) )
>     IFS=$OLD_IFS
>
> (
>     IFS=$'\n' # Must split on newlines only.
>     all_matches=( $( whence -mavS $@ ) )
> )
>
> ... and the interesting thing is that the former executes a stress test in
> ca. 290 mS, but the latter in ca. 250 mS.  The difference isn't significant
> in the real world, but it is hard to understand, it seems strange that the
> subshell would be faster. Is this possible?

$(...) is always going to create one subshell.

How expensive a subshell is, may depend on several things:  How the
operating system implements process forking; how much memory your
current shell is using at the time; how busy the system otherwise is;
what kind of multithreading your processor supports; and so on.

It's quite possible that doing the memory management for the
assignment to all_matches in a newly forked process is faster than in
the original shell (perhaps because the subshell never needs to free
it again?).  There is also some overhead involved in saving/restoring
IFS with "local" which you are avoiding.

Also there's really no reason to do both "local IFS=..." and
"IFS=$OLD_IFS", the whole point of the "local" is to allow zsh to do
the save/restore of IFS for you.  If you only need the change of $IFS
for "whence" then you can do it with an anonymous function:

  (){ local IFS=$'\n'; all_matches=( $( whence -mavS $@ ) ) }

Or you can do it without changing IFS at all, like this:

  all_matches=( ${(f)"$( whence -mavS $@ )"} )

Re: fast subshell

[Ray Andrews]

On 01/04/18 11:39 AM, Bart Schaefer wrote:
>
> It's quite possible that doing the memory management for the
> assignment to all_matches in a newly forked process is faster than in
> the original shell (perhaps because the subshell never needs to free
> it again?).  There is also some overhead involved in saving/restoring
> IFS with "local" which you are avoiding.
It's rather interesting.  I suppose the deepest gurus could actually 
discuss the nuts and bolts in detail.  Meanwhile my fears of some 
dreadful overhead are dead.
>
> Also there's really no reason to do both "local IFS=..." and
> "IFS=$OLD_IFS"
I need the thing restored for use latter in the same function. I've 
since seen that:

(
IFS=...
...
)

Somehow screws up, I'm not sure why but it has effects outside the 
parenthesis.  Issues with a subshell within a subshell?  Don't seem right.
>    (){ local IFS=$'\n'; all_matches=( $( whence -mavS $@ ) ) }
I'll try that.
> Or you can do it without changing IFS at all, like this:
>
>    all_matches=( ${(f)"$( whence -mavS $@ )"} )
>
Now that's the 'real' answer.  Direct control within the statement 
itself.   Gotta get used to these nested parameters, it's not really 
that scary.