Re: Coccinelle: Checking the influence of “Grep query”

Re: Coccinelle: Checking the influence of “Grep query”

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]



On Thu, 22 Oct 2020, Markus Elfring wrote:

> > A disjunction is applied by this script for the semantic patch language.
> > This construct uses short-circuit evaluation. It has got the consequence
> > that the last element of the specified condition will only be checked
> > if all previous parts did not match. Such a technical detail leads to
> > a recommended ordering of condition parts if you would like to care for
> > optimal run time characteristics of SmPL code.
>
> I imagine that such information can trigger further software evolution
> at more places.
>
>
> > +++ b/scripts/coccinelle/iterators/for_each_child.cocci
>
> The software “Coccinelle 1.0.8-00177-g28737419” displays the following data.
>
> elfring@Sonne:~/Projekte/Linux/next-patched> spatch -D patch --parse-cocci
> scripts/coccinelle/iterators/for_each_child.cocci
> …
> Grep query
> for_each_node_with_property || for_each_node_by_type || for_each_node_by_name ||
> for_each_matching_node_and_match || for_each_matching_node ||
> for_each_compatible_node || for_each_child_of_node ||
> for_each_available_child_of_node
>
>
> I suggest to take another closer look at the presented ordering for
> these identifiers.
> It deviates from the proposed listing for the SmPL disjunction.
> Now I am curious if this difference can be meaningful.
>
> If the exact “grep” is performed, it might happen that short-circuit evaluation
> would be applied also by the corresponding software component (or known tool).
> Will any adjustments become relevant then accordingly?

It doesn't matter.  The purpose is just to select files that are relevent
for consideration.  If a file is selected for two reasons instead of one
reason, it doesn't matter; it's still selected.

julia

Re: [Cocci] Coccinelle: Checking the relevanc =?UTF-8?Q?e_of_parentheses_in_=E2=

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]



On Tue, 27 Oct 2020, Markus Elfring wrote:

> > Will any adjustments become relevant then accordingly?
>
> I have found out that the function “interpret” (OCaml code) constructs a command
> and executes it.
> https://github.com/coccinelle/coccinelle/blob/3c01dc1696dc5ccfb319673f205e491b572ee0be/parsing_cocci/git_grep.ml#L9
>
> I have tried a corresponding test display out. Thus I have got the impression
> that desired patterns are passed with extra parentheses.
>
> … git grep -l -w \( -e for_each_node_by_type … -e for_each_node_with_property \) -- '*.c'
>
>
> How do you think about to omit these parentheses here?

Does it make a difference?

julia

Re: [Cocci] Coccinelle: Checking the relevanc =?UTF-8?Q?e_of_parentheses_in_=E2=

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]



On Tue, 27 Oct 2020, Markus Elfring wrote:

> >> … git grep -l -w \( -e for_each_node_by_type … -e for_each_node_with_property \) -- '*.c'
> >>
> >>
> >> How do you think about to omit these parentheses here?
> >
> > Does it make a difference?
>
> I find that it can be nicer to avoid the passing of unnecessary characters.
>
> * The compilation of the affected OCaml source files can eventually benefit
>   from another bit of clean-up, can't it?

I have no idea what this means.

julia

> * The called software components do also not need to fiddle with such extra data then.
>
> Regards,
> Markus
>

Re: Coccinelle: Checking the influence of “Grep query”

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]



On Tue, 27 Oct 2020, Markus Elfring wrote:

> > It doesn't matter.  The purpose is just to select files that are relevent
> > for consideration.  If a file is selected for two reasons instead of one
> > reason, it doesn't matter; it's still selected.
>
> The software “git grep” probably supports also short-circuit evaluation
> for the discussed use case (because command parameters were selected in the way
> that this special functionality would not be excluded).
> https://github.com/git/git/blob/e8ab941b671da6890181aea5b5755d1d9eea24ec/grep.c#L1294
>
> Under which circumstances would potentially measurable effects become more interesting
> so that the reordering of the mentioned identifiers would be reconsidered?
>
>
> elfring@Sonne:~/Projekte/Linux/next-patched> /usr/bin/time git grep --threads 4 -l -w -e 'for_each_node_by_type' -e 'for_each_matching_node_and_match' -e 'for_each_compatible_node' -e 'for_each_available_child_of_node' -e 'for_each_child_of_node' -e 'for_each_matching_node' -e 'for_each_node_by_name' -e 'for_each_node_with_property' -- '*.[ch]' > /dev/null
> 1.55user 0.74system 0:01.24elapsed 183%CPU (0avgtext+0avgdata 78760maxresident)k
> 216inputs+0outputs (3major+30006minor)pagefaults 0swaps
> elfring@Sonne:~/Projekte/Linux/next-patched> /usr/bin/time git grep --threads 4 -l -w -e 'for_each_child_of_node' -e 'for_each_available_child_of_node' -e 'for_each_compatible_node' -e 'for_each_node_by_name' -e 'for_each_node_by_type' -e 'for_each_matching_node' -e 'for_each_matching_node_and_match' -e 'for_each_node_with_property' -- '*.[ch]' > /dev/null
> 1.55user 0.72system 0:01.24elapsed 183%CPU (0avgtext+0avgdata 74380maxresident)k
> 0inputs+0outputs (0major+31030minor)pagefaults 0swaps

As far as I can see, you are showing that the times are the same.  Why are
you wasting your time on this?

Although I didn't know that git grep was parallelizable, although since
the used time and the elapsed time are almost the same, maybe it doesn't
help much.

julia