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

Bug#990294: RFP: explain-pause-mode-el -- Emacs mode for session profiling and identification of poorly performing code



Package: wnpp
Severity: wishlist

* Package name    : explain-pause-mode-el
  Version         : 0.2~dev~gitsnapshot
  Upstream Author : Lin Xu <lin@lastquestion.org>
* URL             : https://github.com/lastquestion/explain-pause-mode
* License         : GPL2+ (appears to be GPL3+ effective)
  Programming Lang: elisp
  Description     : Emacs major mode for session profiling and the identification of poorly performing code

I'm filing this RFP since another team member mentioned that it looked
useful.  Obviously I agree, and this looks like something that should
be in Debian.  If someone else doesn't adopt this bug I expect I'll
package it later this year.  So what does it do?

Explain-pause-mode is an Emacs major mode that provides simple
profiling of an Emacs session; it displays the following data in
columns: Command [name], slow, avg ms, ms, calls.  "Slow" marks the
top offenders for things that are keeping Emacs' single thread busy
and/or are causing latency spikes with interactivity (thus degrading
the user experience and/or making the UI unusable with a combination
of hard-blocking and/or stuttering echoing of input).   It uses a
numerical system that I haven't yet found a definition for, where "0"
presumably correlates to "not an issue", "1" maybe and issue, "2"
definitely and issue, and so on.  "Avg ms, ms" is presumably how long
the call took, and calls is the number of times the command was called
since profiling was initiated.

This software is useful for an average Emacs end user who wonders what
is causing the experience with their favourite editor to be less than
stellar.  It simplifies benchmark.el into something analogous to a
process monitor that provides an answer to "what is making Emacs slow,
and for how long, and how often?"  The ability to effortlessly identify
poorly performing functions will also provide Debian maintainers with
user-facing problems that can be solved with upstream MRs/PRs--said
another way, clear opportunities for upstream contributions.


Best,
Nicholas


Reply to: