bug#40335: 27.0.90; elp-not-profilable not up to date

[Philipp Stephani]

Am Mo., 13. Apr. 2020 um 18:54 Uhr schrieb Štěpán Němec <stepnem@gmail.com>:
>
> On Mon, 13 Apr 2020 12:05:06 -0400
> Noam Postavsky wrote:
>
> >> Right, because that was just an error on my part: `time-subtract' does
> >> in fact exhibit the problem. But its alias `subtract-time' doesn't, even
> >> when advised explicitly. I guess advices ignore aliases (i.e. pass
> >> through to the real definition)?
> >
> > Seems to be the opposite: the advice applies only to the alias, so since
> > elp uses the time-subtract name, advising subtract-time doesn't cause
> > problems.
>
> Indeed, thanks :-D
>
> I wonder what the best way forward is here. (info "(elisp) Profiling")
> states that elp "is limited to profiling functions written in Lisp, it
> cannot profile Emacs primitives". So given that of the problem-makers
> only `error' is a Lisp function, the simplest solution would be just
> replacing `special-form-p' with `subrp' in `elp-profilable-p', thus
> disallowing instrumenting primitives altogether.

That seems a bit too drastic. Some primitives are long-running (e.g.
call-process), and instrumenting them is generally useful and also
supported in practice.

>
> If we want to preserve the partial support for primitives, do we want to
> support as much as possible, e.g. by runtime-checking if
> `elp--make-wrapper' is compiled and determine the set of problem-makers
> dynamically, or do we just update the static `elp-not-profilable' list
> conservatively (i.e., including _all_ functions called from the
> wrappers, to make sure they don't cause problems even when
> `elp--make-wrapper' is run interpreted)?

I think the latter makes the most sense. Probably it would also make
sense to exclude primitives and other functions that are so fast that
instrumenting them never makes sense (car, consp, etc.).