nmake does two things that might make this a non-optimal approach (1) it sends actions to the shell as a block, not line-by-line (2) it supports concurrent action execution
these are done via libcoshell() which for the one host parallel case starts one ksh hanging on two pipes; the multi-host case has the same arrangement to a remote execution server that then attaches to ksh running on multiple systems pretty much after the first non-builtin command executes the cost of starting up the coshell is paid up the protocol on the pipes is the same for both cases this setup gives full control to the shell coprocess which is optimized to fork()/vfork() itself at the right times if nmake linked directly with libshell its adddress space would be combined with the shells in the fork()/vfork() dance a makefile only executing builtins might see an improvement but I think there would have to be a lot of nmake invocations to make it worth it an experiment to see if it would be an improvement or a wash would be to provide a different libcoshell implementation, preserving the current api, that uses libcoshell directly instead of a coshell process if the improvements were substantial that would convince me to change libcoshell to dynamically link libshell for the local-host case On Wed, 6 Jun 2012 13:20:00 +0200 Irek Szczesniak wrote: > Glenn, would it make sense to let nmake (or a POSIX make > implementation) execute targets through libshell? I think it'll give a > good performance gain when shell builtins are involved. > What do you think? _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
