GNU bug report logs - #40335
27.0.90; elp-not-profilable not up to date

Previous Next

Full log

Message #20 received at 40335 <at> debbugs.gnu.org (full text, mbox):

From: Štěpán Němec <stepnem <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 40335 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>
Subject: Re: bug#40335: 27.0.90; elp-not-profilable not up to date
Date: Mon, 13 Apr 2020 18:55:09 +0200

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.

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)?

-- 
Štěpán

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.