Is large `if' or `case' statement a potential cause of a slow-down?

Is large `if' or `case' statement a potential cause of a slow-down?

[Sebastian Gniazdowski]

Hello,
a project (f-sy-h) suffers from what I call a "big-loop". I will
rewrite it with a trick soon to check, but I though, why guess that a
big loop, `if' or `case' are not easy for Zsh engine, while I can ask.
Does someone know a potential marauder script constructs, more
difficult than less difficult for Zsh execution? Is big-loop/if/case
among them? I recall Bart mentioned that long assignment statements in
zcompdump are pretty much slow, IIRC.

On this occasion, I would ask when are functions compiled? Before
first use, or when defining, or maybe different from these both?
Functions in .zwc digest are of course compiled and do not need
compilation at all (?).

To bump up the stake: when sourcing a compiled script that defines
functions, will there be a wordcode for those function definitions and
will Zsh use it avoiding compilation?
-- 
Best regards,
Sebastian Gniazdowski

Re: Is large `if' or `case' statement a potential cause of a slow-down?

[Sebastian Gniazdowski]

Guys is this silence to not openly state that something is not nice ;)
Or was my post e.g. too long. Because when I replaced significant if
(10 conditions if, elif, ..., fi ) with what I call "hue architecture"
(in FSH everything is about colors), described at the end, I've got
performance gain from 300 ms to 47 ms. This is great, not only fast,
but also implements "modularization" that many people like and that
will help fast-syntax-highlighting.

Hue description: suppose there is:

if [[ b = c ]]; then
...
elif [[ a = "b" ]]; then
...
elif [[ b = c ]]; then
...
elif (( 1 )); then
...
fi

It is then possible to put all conditions into array, just by-hand
copy-paste and wrapping with ', and then run:

local cond;
integer idx=1
for cond in "${HUE_ROUTING__SOME}"; do
    cond="$cond && return $idx; "
    HUE_ROUTING__SOME[idx]="$cond"
    idx+=1
done

To obtain array with:
HUE_ROUTING__SOME=(
    '[[ b = c ]] && return 1'
    '[[ a = "b" ]] && return 2'
    '[[ b = c ]] && return 3'
    '(( 1 )) && return 4'
)

And then do:

() { eval "${HUE_ROUTING__SOME[@]}"; }; index=$?

to obtain index into second table that maps 1...N integers on names of
functions to run.

All that may seem long, but almost everything is stored once and
active is only this part (example from upcoming FSH):

() { eval "${FAST_ROUTING__NONE[@]}"; }
${(0)FAST_DISPATCH__NONE[$?]}

So my dispatch table (the second one) holds code to be run like this:
local$'\0'a=b.

So 2 lines instead of big if monolith. So happy :)


On 12 June 2018 at 19:27, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> Hello,
> a project (f-sy-h) suffers from what I call a "big-loop". I will
> rewrite it with a trick soon to check, but I though, why guess that a
> big loop, `if' or `case' are not easy for Zsh engine, while I can ask.
> Does someone know a potential marauder script constructs, more
> difficult than less difficult for Zsh execution? Is big-loop/if/case
> among them? I recall Bart mentioned that long assignment statements in
> zcompdump are pretty much slow, IIRC.
>
> On this occasion, I would ask when are functions compiled? Before
> first use, or when defining, or maybe different from these both?
> Functions in .zwc digest are of course compiled and do not need
> compilation at all (?).
>
> To bump up the stake: when sourcing a compiled script that defines
> functions, will there be a wordcode for those function definitions and
> will Zsh use it avoiding compilation?
> --
> Best regards,
> Sebastian Gniazdowski

Re: Is large `if' or `case' statement a potential cause of a slow-down?

[Bart Schaefer]

On Wed, Jun 13, 2018 at 7:57 AM, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> Guys is this silence to not openly state that something is not nice ;)

In my case it's because I don't presently have time to do more than
toss off a quick one-line reply, and (aside from not being exactly
sure what "big-loop" means), this needs a lot more depth.

Re: Is large `if' or `case' statement a potential cause of a slow-down?

[Sebastian Gniazdowski]

On 13 June 2018 at 17:20, Bart Schaefer <schaefer@brasslantern.com> wrote:
> In my case it's because I don't presently have time to do more than
> toss off a quick one-line reply, and (aside from not being exactly
> sure what "big-loop" means), this needs a lot more depth.

Basing on FSH, such big-loop doesn't call functions. What emerges is
thus a long, non-structular code (IIRC, lack of meaningful functions
<=> no structural programming). It's like having one function that
does everything. Here one big-loop does everything. And it contains
other "does-everything" constructs, like big-ifs and big-cases. One
`case' in FSH code has 6 screens (30 lines each). Whole loop has 18
screens. That's why this is great, to decompose this big-loop, and
even gain (that much) performance. This also suggests that the answer
to the initial question is: yes, big if, case, etc. can harm
performance.

-- 
Best regards,
Sebastian Gniazdowski

Re: Is large `if' or `case' statement a potential cause of a slow-down?

[Sebastian Gniazdowski]

On 13 June 2018 at 16:57, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> So 2 lines instead of big if monolith. So happy :)

And now I have to call it of :( I didn't copy routing tables into test
script, eval was working on empty string silently, ${(0)cmd} was also
silent. So no decomposition of 18-pages loop :(

-- 
Best regards,
Sebastian Gniazdowski