[Gambas-user] (To Benoit) - About SHELL slowlyness

[Doriano Blengino]

Benoît Minisini ha scritto:
>> Benoit, you are right when you say "there is no reason why SHELL should
>> be slow", 
>>     
>
> I didn't say that. I was talking about the EXEC instruction. The SHELL 
> instruction runs a program inside /bin/sh, whereas EXEC runs it directly.
>
> In other words,
>
> SHELL "abcd"
>
> <=> EXEC [ "/bin/sh", "-c", "abcd" ]
>
> So it is logical that you find Gambas slower. You are actually comparing 
> Gambas + bash with bash alone!
>   

And, if fact, my bash command line was exactly <...do sh -c "rm blah 
blah blah">.
It is the same situation - gambas invokes a SHELL (which is sh -c), and 
bash invokes sh -c.
But last night a doubt arised: is bash so smart to understand that there 
is no need to do a fork() followed by exec(), when after a fork() bash 
image is already in ram? Even if so, bash should do some kind of 
reinitialization on its data segment, because after a fork() its data 
are the same as the parent bash. Sounds like the same thing...

I didn't mentioned that my gambas app also uses EXEC, to invoke external 
plugins. My impression is the same - EXEC seems slow (not too slow, just 
a little). I didn't tested that situations because it was more 
complicated - the SHELL case was more simple to test. But there is a 
difference in usage: with gambas I always redirect stdout (in both SHELL 
and EXEC); my tests with command line didn't redirect output. I think 
redirection should have little cost, but I could be wrong. The command, 
which uses redirection:

  time for a in *; do res=$(sh -c "cp $a /tmp"); done

takes 1.88 seconds (1.78 with no redirection). Redirection *is* a cost; 
but bit too big. And bash is still quicker than gambas.

Well, this email was just for completeness.

Regards,

-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."