Подсказки для профилирования неправильного поведения Emacs Lisp?
Реализация nowInMicrosSinceEpoch() неверна. Значение в миллисекундах применяется дважды.
Чтобы показать это, вот код Java для печати значений, используемых в nowInMicrosSinceEpoch():
Instant now = Instant.now();
System.out.println(now);
System.out.printf("%23d toEpochMilli()%n", now.toEpochMilli());
System.out.printf("%26d toEpochMilli() * 1000 = a%n", now.toEpochMilli() * 1000L);
System.out.printf("%29d getNano()%n", now.getNano());
System.out.printf("%26d getNano() / 1000 = b%n", now.getNano() / 1000L);
System.out.printf("%26d a + b%n", now.toEpochMilli() * 1000L + now.getNano() / 1000L);
Вывод
2019-02-02T00:16:58.999999999Z
1549066618999 toEpochMilli()
1549066618999000 toEpochMilli() * 1000 = a
999999999 getNano()
999999 getNano() / 1000 = b
1549066619998999 a + b
Так, когда часы при переключении с x:58.999999999Z на x:59.000000000Z вы получаете:
2019-02-02T00:16:59.000000000Z
1549066619000 toEpochMilli()
1549066619000000 toEpochMilli() * 1000 = a
000000000 getNano()
000000 getNano() / 1000 = b
1549066619000000 a + b
Значение, равное 1 наносекунде позже, возвращает значение, которое на 998999 микросекунд раньше.
Расчетное значение работает с удвоенной скоростью и каждую секунду откатывается назад на 1 секунду.
Правильная формула (на Java):
Instant now = Instant.now();
return now.getEpochSecond() * 1000000L + now.getNano() / 1000L;
4 ответа
Предложение установки debug-on-quit к t так, чтобы можно было узнать то, что готов Emacs, является хорошим. Можно думать об этом как являющемся формой выборки профилирования с единственным образцом: часто единственный образец - все, в чем Вы нуждаетесь.
Обновление: Запуск с версии 24.3, Emacs содержит два профилировщики. Существует (новый) профилировщик выборки в profiler.el и (старый) оснащающий профилировщик в elp.el.
профилировщик выборки зарегистрирован здесь . Это довольно просто для использования:
, Чтобы начать представлять, тип
M-x profiler-start. Можно принять решение представить использованием процессора, использованием памяти или обоими. После выполнения некоторой работы, типM-x profiler-reportдля отображения сводного буфера для каждого ресурса, который Вы приняли решение представить. Когда Вы закончили представлять, типM-x profiler-stop.
Здесь является некоторым выводом в качестве примера от cpu+mem сессия профилировщика с интеграция Perforce/Emacs , что я поддерживаю. Я развернул самую верхнюю функцию (progn) для обнаружения , куда использование процессорного времени и памяти происходит от [1 123].
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, таким образом, выглядит, как будто я мог сохранить много процессорного времени и памяти [1 124] локально привязка inhibit-modification-hooks к [1 113] вокруг этого кода .
можно также использовать Профилировщика Lisp Emacs. Это находится скорее под - зарегистрировано: необходимо будет прочитать комментарии в [1 114] для получения дополнительной информации но в основном Вы работаете elp-instrument-package для включения профилирования для всех функций с данным префиксом, и затем elp-results для наблюдения результатов.
Вот некоторый типичный вывод после ввода M-x elp-instrument-package RET c- RET, fontifying 4 000 строк 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 для нахождения его наверняка) затем, профилировщик может помочь Вам диагностировать проблему подробно.
Имейте Вас попробованный: 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, когда это, будет казаться, заморозится. Может быть более легкий способ сделать это.........
С dope.el можно представить весь .emacs или несколько elisp файлов, загруженных при запуске. Загрузите его от , www.gnufans.net/~deego/pub/emacspub/lisp-mine/dope/
M-x dope-quick-start покажет немного вводного учебного руководства.
Редактирование: исходный URL является ныне несуществующим, но на Концентраторе Мерзавца существует рабочее зеркало:
https://raw.github.com/emacsmirror/dope/master/dope.el
Это не, строго говоря, ответ на Ваш вопрос, а скорее, чем выполнение comment-out-and-restart вещи, можно запустить emacs с -q опция, загрузить .emacs в буфер и оценить каждый sexpr сами с C-x C-e для разыскивания нарушающего.