* Re: Coccinelle: Checking the influence of “Grep query” [not found] ` <acaed49b9195d47e252a0b67551f87e96324d004.camel@web.de> @ 2020-10-22 12:35 ` Julia Lawall [not found] ` <6fe4c63d-1b7e-b947-139c-423edc519d2f@web.de> [not found] ` <45310257-201a-40ea-348f-b8e909c3775c@web.de> 1 sibling, 1 reply; 4+ messages in thread From: Julia Lawall @ 2020-10-22 12:35 UTC (permalink / raw) To: Markus Elfring Cc: Michal Marek, Gilles Muller, kernel-janitors, Nicolas Palix, linux-kernel, Julia Lawall, Coccinelle [-- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <6fe4c63d-1b7e-b947-139c-423edc519d2f@web.de>]
* Re: Coccinelle: Checking the influence of “Grep query” [not found] ` <6fe4c63d-1b7e-b947-139c-423edc519d2f@web.de> @ 2020-10-28 6:50 ` Julia Lawall 0 siblings, 0 replies; 4+ messages in thread From: Julia Lawall @ 2020-10-28 6:50 UTC (permalink / raw) To: Markus Elfring Cc: Michal Marek, Gilles Muller, kernel-janitors, Nicolas Palix, linux-kernel, Julia Lawall, Coccinelle [-- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <45310257-201a-40ea-348f-b8e909c3775c@web.de>]
* Re: [Cocci] Coccinelle: Checking the relevanc =?UTF-8?Q?e_of_parentheses_in_=E2= [not found] ` <45310257-201a-40ea-348f-b8e909c3775c@web.de> @ 2020-10-27 10:55 ` Julia Lawall [not found] ` <bfb3e786-a64f-ecaf-eb37-8bd6b53cf38a@web.de> 0 siblings, 1 reply; 4+ messages in thread From: Julia Lawall @ 2020-10-27 10:55 UTC (permalink / raw) To: Markus Elfring Cc: Michal Marek, Gilles Muller, kernel-janitors, Nicolas Palix, linux-kernel, Coccinelle [-- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <bfb3e786-a64f-ecaf-eb37-8bd6b53cf38a@web.de>]
* Re: [Cocci] Coccinelle: Checking the relevanc =?UTF-8?Q?e_of_parentheses_in_=E2= [not found] ` <bfb3e786-a64f-ecaf-eb37-8bd6b53cf38a@web.de> @ 2020-10-27 12:03 ` Julia Lawall 0 siblings, 0 replies; 4+ messages in thread From: Julia Lawall @ 2020-10-27 12:03 UTC (permalink / raw) To: Markus Elfring Cc: Michal Marek, Gilles Muller, kernel-janitors, Nicolas Palix, linux-kernel, Coccinelle [-- 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 > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-10-28 6:50 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <78f8b08754dde286adf7e11e1eeb3bb8ad500d8b.camel@web.de> [not found] ` <acaed49b9195d47e252a0b67551f87e96324d004.camel@web.de> 2020-10-22 12:35 ` Coccinelle: Checking the influence of “Grep query” Julia Lawall [not found] ` <6fe4c63d-1b7e-b947-139c-423edc519d2f@web.de> 2020-10-28 6:50 ` Julia Lawall [not found] ` <45310257-201a-40ea-348f-b8e909c3775c@web.de> 2020-10-27 10:55 ` [Cocci] Coccinelle: Checking the relevanc =?UTF-8?Q?e_of_parentheses_in_=E2= Julia Lawall [not found] ` <bfb3e786-a64f-ecaf-eb37-8bd6b53cf38a@web.de> 2020-10-27 12:03 ` Julia Lawall
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).