From: "Martin Ågren" <martin.agren@gmail.com>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: Denton Liu <liu.denton@gmail.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: coccinelle: merge two rules from flex_alloc.cocci
Date: Thu, 14 Nov 2019 07:37:20 +0100 [thread overview]
Message-ID: <CAN0heSqyGwkeGKv0m_gLDooaUp=gN2_tD7kJYNxeL7LALiPRhQ@mail.gmail.com> (raw)
In-Reply-To: <ff240bc1-ae2a-17e5-d149-2d08c5367e96@web.de>
On Wed, 13 Nov 2019 at 22:10, Markus Elfring <Markus.Elfring@web.de> wrote:
>
> >>> This script contained two transformation rules for the semantic patch language
> >>> which used duplicate code.
> >>> Thus combine these rules by using a SmPL disjunction for the replacement
> >>> of two identifiers.
> >
> > My knowledge of coccinelle and cocci rules is basically zero,
>
> Would you like to change this situation eventually?
Possibly, yeah, but I think the key word there is "eventually". ;-)
But maybe I'll learn something from this exchange.
> > but my impression from this list is that running "make coccicheck"
> > can be expensive, both in terms of time and memory.
>
> The desired source code analysis to detect possible software transformations
> needs additional data processing resources.
> It is usually hoped that corresponding efforts will help with development
> approaches at other places.
Right. So by that logic, if this patch doubles the memory usage and/or time
consumption of "make coccicheck", wouldn't this patch be affecting those
other activities at other places of the code negatively? ;-)
I'm not saying that this patch DOES affect the time/memory usage
negatively, and I'm not saying this patch IS a net negative. Definitely
not. It's just that considering, e.g., 960154b9c1 ("coccicheck:
optionally batch spatch invocations", 2019-05-06), time/memory
consumption -- and the balancing of the two -- seems to be an actual
real-world issue here, worth thinking about.
(That commit message mentions that processing all source files in one go
requires close to 2GB of memory. We've since started processing more
files.)
> > Do these patches help there in any way?
>
> I hope so to some degree.
If you could have some before/after numbers, that would be cool. If you
collect your patches into one series, you could at least do measurements
before/after the series.
Or if you could make some other sort of claim around "this shouldn't
affect this-or-that because so-and-so".
> How much do you care to avoid code duplication?
I tend to like it, everything else equal.
> > Or could they hurt?
>
> I assume that you ask according to the presented change possibilities
> for Git's SmPL scripts (and not only for “flex_alloc.cocci”).
>
> Some changes usually contain the risk for undesirable effects.
> Would you like to clarify each of them in more detail?
Do you mean whether I would like to clarify the risks I see, or do you
mean whether I would like you to clarify which you see? I've tried to
clarify the one I see -- based on passively observing cocci-related
patches floating around this list. If you see other potential risks,
feel free to mention them.
You seem to know lots more than I do about these things. I wouldn't be
surprised if you know more on this than most or all other participants
on this list, so feel free to share some of that in the commit messages
so that others can understand how you've reasoned.
Martin
next prev parent reply other threads:[~2019-11-14 6:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-12 15:34 [PATCH] coccinelle: merge two rules from flex_alloc.cocci Markus Elfring
2019-11-12 17:59 ` Denton Liu
2019-11-13 18:27 ` Martin Ågren
2019-11-13 21:10 ` Markus Elfring
2019-11-14 6:37 ` Martin Ågren [this message]
2019-11-14 8:15 ` Markus Elfring
2019-11-14 16:35 ` SZEDER Gábor
2019-11-14 17:30 ` Markus Elfring
2019-11-15 5:13 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAN0heSqyGwkeGKv0m_gLDooaUp=gN2_tD7kJYNxeL7LALiPRhQ@mail.gmail.com' \
--to=martin.agren@gmail.com \
--cc=Markus.Elfring@web.de \
--cc=git@vger.kernel.org \
--cc=liu.denton@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).