descargar - emacs para linux

Consejos para perfilar mal comportamiento Emacs Lisp?

Question

Personalizo mucho Emacs. Recientemente, agregué algo a mi configuración de .emacs que fija esporádicamente mi CPU al 100%, pero realmente no sé de qué se trata.

Si presiono Cg varias veces, al final recibiré un mensaje debajo del minibúfer preguntándome si quiero guardar automáticamente mis archivos y luego si deseo abortar los emacs por completo. Si sigo diciendo que no y presionando Cg, eventualmente podré volver a ejecutar emacs como siempre. Una hora más tarde volverá a suceder.

Podría seguir haciendo lo mismo que yo, comentando varias cosas que he agregado recientemente, reiniciando emacs, tratando de reducir al culpable, pero es lento.

¿Hay alguna manera de que pueda perfilar emacs directamente para descubrir qué función lisp está acaparando a la CPU?

Answer 1

¿Has probado: Options->Enter debugger on Quit/Cg ? (esto está en emacs22)

Si necesita depurar la puesta en marcha de emacs: use emacs -q --no-site-file , visite sus .emacs (o site-start.el o lo que sea), active la opción del menú Options->Enter debugger on Quit/Cg , y luego el elemento del menú Emacs-Lisp->Evaluate buffer y Cg cuando parece congelarse. Puede haber una manera más fácil de hacer esto .........

Answer 2

Esto no es, estrictamente hablando, una respuesta a su pregunta, pero en lugar de hacer el comentario de reiniciar, puede iniciar emacs con la opción -q , cargar sus .emacs en un búfer y evaluar cada sexpr usted mismo con Cx Ce para rastrear el delincuente.

Answer 3

Con dope.el puede crear perfiles de .emacs completos o múltiples archivos elisp cargados al inicio. Descárguelo de www.gnufans.net/~deego/pub/emacspub/lisp-mine/dope/

Mx dope-quick-start mostrará un pequeño tutorial de introducción.

Editar: La URL original ahora está desaparecida, pero hay un espejo que funciona en Git Hub:
https://raw.github.com/emacsmirror/dope/master/dope.el

Answer 4

La sugerencia de establecer debug-on-quit en t para que pueda averiguar qué está haciendo Emacs es una buena idea. Puede pensar en esto como una forma de muestreo de perfiles con una sola muestra: a menudo, una sola muestra es todo lo que necesita.

Actualización: comenzando con la versión 24.3, Emacs contiene dos perfiladores. Hay un (nuevo) generador de profiler.el muestreo en profiler.el y un perfilador de instrumentos (antiguo) en elp.el

El generador de perfiles de muestreo está documentado aquí . Es bastante sencillo de usar:

Para comenzar a perfilar, escriba Mx profiler-start . Puede elegir el perfil según el uso del procesador, el uso de la memoria o ambos. Después de hacer un poco de trabajo, escriba Mx profiler-report para mostrar un búfer de resumen para cada recurso que elija para crear un perfil. Cuando haya terminado de perfilar, escriba Mx profiler-stop .

Aquí hay algunos ejemplos de salida de una sesión de perfil de cpu+mem con la integración de Perforce / Emacs que mantengo. progn función más alta ( progn ) para averiguar de dónde proviene el tiempo de CPU y el uso de la memoria .

Function                                            Bytes    %
- progn                                        26,715,850  29%
  - let                                        26,715,850  29%
    - while                                    26,715,850  29%
      - let                                    26,715,850  29%
        - cond                                 26,715,850  29%
          - insert                             26,715,850  29%
            + c-after-change                   26,713,770  29%
            + p4-file-revision-annotate-links       2,080   0%
+ let                                          20,431,797  22%
+ call-interactively                           12,767,261  14%
+ save-current-buffer                          10,005,836  11%
+ while                                         8,337,166   9%
+ p4-annotate-internal                          5,964,974   6%
+ p4-annotate                                   2,821,034   3%
+ let*                                          2,089,810   2%

Puede ver que el culpable es c-after-change , por lo que parece que podría ahorrar una gran cantidad de tiempo de CPU y memoria al enlazar localmente inhibit-modification-hooks para rodear este código .

También puede usar el Emacs Lisp Profiler. Esto no está elp.el documentado: tendrá que leer los comentarios en elp.el para obtener más información, pero básicamente ejecuta el elp-instrument-package para activar el perfilado de todas las funciones con un prefijo dado, y luego elp-results para ver los resultados

Este es un resultado típico después de escribir Mx elp-instrument-package RET c- RET , que genera 4.000 líneas de C y luego ejecuta elp-results (y usa elp-sort-by-function para ordenar por conteo de llamadas):

Function Name                  Call Count  Elapsed Time  Average Time
=============================  ==========  ============  ============
c-skip-comments-and-strings    107         0.0           0.0
c-valid-offset                 78          0.0           0.0
c-set-offset                   68          0.031         0.0004558823
c-end-of-macro                 52          0.0           0.0
c-neutralize-CPP-line          52          0.0           0.0
c-font-lock-invalid-string     20          0.0           0.0
c-set-style-1                  19          0.031         0.0016315789
...

En su caso particular, el generador de perfiles no ayuda de inmediato, porque no sabe qué paquete tiene la culpa. Pero si puede adivinar (o usar debug-on-quit para encontrarlo con seguridad), el generador de perfiles puede ayudarlo a diagnosticar el problema en detalle.