bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Štěpán Němec
Subject: bug#40335: 27.0.90; elp-not-profilable not up to date
Date: Mon, 13 Apr 2020 18:55:09 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]