[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#40335: 27.0.90; elp-not-profilable not up to date,
Lars Ingebrigtsen <=