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: Lars Ingebrigtsen
Subject: bug#40335: 27.0.90; elp-not-profilable not up to date
Date: Sat, 18 Sep 2021 18:44:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Štěpán Němec <stepnem@gmail.com> writes:

> 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.

I think it means that it can't profile the innards of C functions -- but
doing `M-x elp-profile-function RET - RET' works fine, as far as I can
tell?

(dotimes (i 1000)
  (- 1 2))

`M-x elp-results RET':

-              1000        0.000410623   4.10623e-07

> 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 we should just update `elp-not-profilable', but we should assume
that `elp--make-wrapper' is byte-compiled.  (Otherwise it'd be less
useful.)

Anybody have any other opinions here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





reply via email to

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