Советы по профилированию неправильного использования Emacs Lisp?

Я очень много настраиваю Emacs. Недавно я добавил что-то в мою конфигурацию .emacs, которая спорадически привязывает мой процессор на 100%, но я действительно не знаю, что это такое.

Если я нажму C-g несколько раз, в конце концов, я получу сообщение ниже минибуфера, спрашивающего меня, хочу ли я автоматически сохранять мои файлы, а затем, если я хочу полностью прервать emacs. Если я продолжаю говорить "нет" и поддерживаю нажатие C-g, в конечном итоге я смогу вернуться к запуску emacs, как обычно. Примерно через час это произойдет снова.

Я бы продолжал работать, как я, комментируя различные вещи, которые я добавил недавно, перезапуская emacs, пытаясь сузить виновника, но это замедляется.

Есть ли способ, с помощью которого я могу профилировать emacs напрямую, чтобы выяснить, что функция lisp забивает процессор?

Ответ 1

Предложение настройки debug-on-quit to t, чтобы вы могли узнать, что такое Emacs, является хорошим. Вы можете думать об этом как о форме профилирования выборки с помощью одного образца: часто вам нужен только один образец.

Обновление: Начиная с версии 24.3, Emacs содержит два профилировщика. В profiler.el есть (новый) пробоотборник пробоотбора и (старый) инструментальный профилировщик в elp.el.

Профайлер пробоотбора описан здесь. Это довольно просто:

Чтобы начать профилирование, введите M-x profiler-start. Вы можете выбрать профиль, используемый процессором, использование памяти или и то, и другое. После выполнения некоторой работы введите M-x profiler-report, чтобы отобразить сводный буфер для каждого ресурса, который вы выбрали для профиля. Закончив профилирование, введите M-x profiler-stop.

Вот пример из вывода cpu+mem profiler с Perforce/Emacs integration, который я поддерживаю. Я расширил самую верхнюю функцию (progn), чтобы узнать где время процессора и использование памяти исходят от.

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%

Вы можете видеть, что виновник c-after-change, поэтому мне кажется, что я могу сэкономить много времени и памяти процессора локальное связывание inhibit-modification-hooks до t вокруг этого кода.

Вы также можете использовать Profiler Emacs Lisp. Это скорее недостаточно документально: вам нужно будет прочитать комментарии в elp.el для деталей, но в основном вы запускаете elp-instrument-package, чтобы включить профилирование для всех функций с заданным префиксом, а затем elp-results, чтобы увидеть результаты.

Вот типичный вывод после ввода M-x elp-instrument-package RET c- RET, затенение 4000 строк C, а затем запуск elp-results (и использование elp-sort-by-function для сортировки по количеству вызовов):

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

В вашем конкретном случае профайлер не помогает сразу, потому что вы не знаете, какой пакет неисправен. Но если вы можете сделать предположение (или использовать debug-on-quit, чтобы найти его наверняка), то профилировщик может помочь вам детально диагностировать проблему.

Ответ 2

Вы пробовали: Options->Enter debugger on Quit/C-g? (это находится на emacs22)

Если вам нужно отлаживать запуск emacs: используйте emacs -q --no-site-file, посетите .emacs (или site-start.el или что-то еще), активируйте пункт меню Options->Enter debugger on Quit/C-g, а затем пункт меню Emacs-Lisp->Evaluate buffer и C-g, когда он замерзнет. Там может быть более простой способ сделать это.........

Ответ 3

С dope.el вы можете профилировать все файлы .emacs или несколько файлов elisp, загруженных при запуске. Загрузите его из www.gnufans.net/~deego/pub/emacspub/lisp-mine/dope/

M-x dope-quick-start покажет небольшое введение.

Изменить: Исходный URL-адрес теперь не функционирует, но есть рабочее зеркало на Git Hub:
https://raw.github.com/emacsmirror/dope/master/dope.el

Ответ 4

Это не является, строго говоря, ответом на ваш вопрос, но вместо того, чтобы делать что-то из комментариев и перезапуска, вы можете запустить emacs с опцией -q, загрузить ваши .emacs в буфер и оценить каждый из сексеров сам с Cx Ce, чтобы отследить оскорбительный.