From: Markus Elfring <Markus.Elfring@web.de>
To: Julia Lawall <julia.lawall@inria.fr>,
Denis Efremov <efremov@linux.com>,
Coccinelle <cocci@systeme.lip6.fr>
Cc: Michal Marek <michal.lkml@markovi.net>,
Gilles Muller <Gilles.Muller@lip6.fr>,
Nicolas Palix <nicolas.palix@imag.fr>,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
Alexander Popov <alex.popov@linux.com>
Subject: Re: [Cocci] Determination of an usage statistic for memory allocation calls
Date: Sun, 18 Oct 2020 18:46:53 +0200 [thread overview]
Message-ID: <51716926.XVqqe9kqm5@sonne> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2010181819210.2759@hadrien>
> > Can such facts influence the specification of efficient SmPL disjunctions another bit?
>
> On my machine, putting the three functions that you have foudn to be the
> most frequent at the end of each disjunction has no impact on the performance.
I propose to reconsider this view.
> So what do you suggest?
1. I would appreciate if you would share more technical details about your test environment
for a safer comparison.
2. The observed software behaviour can be clarified further, can't it?
Aspects like the following can trigger corresponding development considerations.
* “noticable” differences (depending on the run time environment)
* measurable effects
* mathematical properties of an algorithm
Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
prev parent reply other threads:[~2020-10-18 20:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 9:46 [Cocci] [PATCH v8] coccinelle: api: add kfree_mismatch script Markus Elfring
2020-10-16 10:07 ` Julia Lawall
2020-10-16 10:56 ` Markus Elfring
2020-10-18 16:00 ` [Cocci] Determination of an usage statistic for memory allocation calls Markus Elfring
2020-10-18 16:20 ` Julia Lawall
2020-10-18 16:20 ` Julia Lawall
2020-10-18 16:20 ` Julia Lawall
2020-10-18 16:46 ` Markus Elfring [this message]
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=51716926.XVqqe9kqm5@sonne \
--to=markus.elfring@web.de \
--cc=Gilles.Muller@lip6.fr \
--cc=alex.popov@linux.com \
--cc=cocci@systeme.lip6.fr \
--cc=efremov@linux.com \
--cc=julia.lawall@inria.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.lkml@markovi.net \
--cc=nicolas.palix@imag.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.