Hello, I've occurred a comment in exec.c, from year 2000: * Pipelines like the one above are executed by the functions in this file * which call each other (and sometimes recursively). The one above, for * example would lead to a function call stack roughly like: * * execlist->execpline->execcmd->execwhile->execlist->execpline This casts some light on attached profiling-stack-traces (OS X tool Instruments; images compressed by pngcrunch). The stack traces are very deep. I am pretty sure that the test script (ran by the Zsh controled by the profiler) doesn't do pipes. So a conclusion can be made: - Zsh code execution is emerging from from rich number of calls to exec.c functions, - general-purpose or not-final calls are done, equilibrium is established, each Zsh script part finds its (convoluted) way to execsimple, prefork, addvars, - like in Prolog (but maybe in reversed direction), where each theorem finds its top truths in many stages. CPU time is dissipated over exec.c calls, profiling confirms this. I'm trying to alter custom zcompile to limit the depth in case where there are no pipes. Can someone help with this? I can only state that execsimple() and Z_SIMPLE, WC_SUBLIST_SIMPLE are related. However, following comment: * Lists and sublists may also be simplified, indicated by the presence * of the Z_SIMPLE or WC_SUBLIST_SIMPLE flags. In this case they are only * followed by a slot containing the line number, not by a WC_SUBLIST or * WC_PIPE, respectively. and some exec.c-reading hints, that the "not-following by WC_SUBLIST" means no-argumets for executed function, builtin, etc. So, if an entity has arguments, it will require to invoke another recursive execpline2, because execsimple() cannot be used. Is something possible here? -- Sebastian Gniazdowski psprint /at/ zdharma.org
Attachment:
execpline2_a.png
Description: PNG image
Attachment:
execpline2_b.png
Description: PNG image
