Почему запуск Emacs в Windows занимает больше времени, чем в Linux?


14

Конфигурация:

  • Одна система
  • ОС Windows 10 как двойная загрузка
  • ОС Ubuntu 15.10 в качестве двойной загрузки
  • Emacs 25.0.1 с графическим интерфейсом

У меня есть один dot-emacsфайл и все в моей .emacs.dпапке (пакеты также находятся в .emacs.d). Все эти файлы находятся в одной папке Dropbox.

В Windows 10: я поставил символическую ссылку dot-emacsи .emacs.dиз домашней папки в Windows в расположение в Dropbox.

В Linux / Ubuntu 15.10: я также поставил символическую ссылку dot-emacsи .emacs.dиз моей домашней папки Ubuntu (/ home / user /) в расположение в Dropbox.

Таким образом, все файлы, связанные с Emacs, хранятся в одной папке Dropbox в разных операционных системах.

Windows и Linux работают как с двойной загрузкой на одном диске, так и на том же оборудовании.

Когда я запускаю Emacs в Windows, требуется 7,4 секунды для запуска.

Когда я запускаю Emacs в Linux, запуск занимает всего 2,3 секунды.

Это как с Emacs с графическим интерфейсом, так и с версией 25.0.1. Обе операционные системы расположены на одном компьютере на одном и том же диске SSD. Так что это тоже самое оборудование.

Следующие вещи идентичны в операционной системе (Windows 10 и Ubuntu 15.10):

  • Программное обеспечение Emacs, версия 25.0.1
  • Конфигурационные файлы (.emacs.d)
  • Один жесткий диск (все файлы внутри `.emacs.d) и обе ОС находятся на одном SSD).
  • аппаратные средства

Одно отличие:

  • Скомпилированный Emacs для Windows или Linux работает на платформе Windows или Linux соответственно. Это единственная разница.

Я изо всех сил пытаюсь понять, почему Emacs заметно короче время запуска в Ubuntu, чем Windows.


2
Вы забыли упомянуть, что это за сборка. Кроме того, вы должны сравнивать время запуска пустой сессии Emacs с emacs -Q.
Васамаса

Мне нужно (message emacs-init-time)измерить время запуска. Насколько я знаю, это не ограничено функцией. Так, как я мог измерить это с emacs -Qтогда?
ReneFroger

1
M-x emacs-init-time RET
Джордано

1
Я тоже вижу эту проблему ... моему emacs требуется 5-6 секунд для запуска в Linux, но до минуты в Windows. К счастью, Windows не является моей основной ОС на работе.
Каушал Моди

1
Я думаю, это потому, что GCC. Windows Emacs скомпилирован в GCC, который не очень хорош в Windows, есть много ошибок и так далее. Если есть способ скомпилировать EMACS с помощью Visual C ++, я бы хотел увидеть производительность.
Жоау Пауло Андраде

Ответы:


21

Заметка: Windows работает медленно.

Я регулярно использую Emacs как для Windows (Cygwin и native), так и для GNU / Linux (Arch), и я это тоже заметил. Я полагаю, что ответ заключается в том, что Linux во многих областях просто быстрее, чем Windows, особенно в операциях с файловой системой 1 и операциях с потоками / разветвлениями 2 .

Я думаю, что различие в производительности наиболее заметно иллюстрируется при использовании git, и особенно Magit (поскольку он выполняет довольно много команд для своего буфера состояния). Git ужасно медленно работает на Windows. На самом деле он настолько медленный, что я часто редактирую код в Windows в своей папке Dropbox, жду, пока он синхронизируется с моим Linux VPS, и затем использую Magit через SSH, вместо того, чтобы просто использовать его в Windows.

Работа time git statusв главной ветке Emacs занимает в среднем 0,025 секунды для меня. В Windows (родной) это занимает 0,075–0,100 секунд, в Windows (Cygwin) - 0,200 секунд. Это может показаться не таким уж большим, но это означает, что в Windows это в 3-4 раза медленнее.

Следует также отметить, что некоторые антивирусные программы (в частности, McAfee) могут вызвать значительное замедление работы. С включенным McAfee On-Access Scanner все заметно медленнее для меня. Cygwin's git statusможет занять до 2 минут! Только после выключения я получаю время, указанное выше.


В сторону: я только что нашел переменную magit-refresh-verbose, которая обновляет статус. Вот несколько раз для обновления magit-statusбуфера в основной ветке Emacs:

Windows (родная)

GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-04-11 on LEG570
Magit 20151028.1649, Git 2.6.1.windows.1, Emacs 24.5.1
Refreshing buffer `*magit: emacs'...done (9.317s)
Refreshing buffer `*magit: emacs'...done (9.318s)
Refreshing buffer `*magit: emacs'...done (9.357s)

Windows (Cygwin)

GNU Emacs 25.0.50.1 (i686-pc-cygwin) of 2015-07-29 on NAND-LT
Magit 20151015.22, Git 2.5.0.234.gefc8a62, Emacs 25.0.50.1
Refreshing buffer `*magit: emacs'...done (4.609s)
Refreshing buffer `*magit: emacs'...done (4.720s)
Refreshing buffer `*magit: emacs'...done (4.626s)

GNU / Linux (Arch, худшее оборудование, VPS)

GNU Emacs 25.0.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.2) of 2015-10-26
Magit 20151028.1649, Git 2.6.2, Emacs 25.0.50
Refreshing buffer ‘*magit: emacs’...done (0.517s)
Refreshing buffer ‘*magit: emacs’...done (0.507s)
Refreshing buffer ‘*magit: emacs’...done (0.523s)

Более высокая скорость Cygwin удивила меня.

  1. http://www.slideshare.net/PrincipledTechnologies/comparing-file-system-performance-red-hat-enterprise-linux-6-vs-microsoft-windows-server-2012

  2. /programming/12878980/speed-performance-of-a-qt-program-windows-vs-linux


Вы пытались добавить путь для команд, связанных с git exec-path? ( stackoverflow.com/questions/16884377/… ) В моем случае это значительно улучшило скорость.
Joon

1
@joon Да, все соответствующие пути уже в моем exec-path.
няня

Я вижу - я должен проверить это в Linux-коробке. Благодарность!
Joon

@ джун Нет проблем. Если вы найдете способ ускорить это в Windows, пожалуйста, дайте мне знать. Это действительно боль.
няня

1
Но вопрос все еще стоит ... даже без Git, почему Emacs заметно медленнее в Windows?
ReneFroger

0

Может быть, вы можете попытаться настроить emacs-сервер, чтобы вам было удобнее. Используя этот подход или запустив emacs в качестве демона, вы можете просто использовать emacsclient для запуска новых окон, не загружая другой экземпляр emacs. Это хороший подход. Я не проверял это в Windows, но вот ссылка, которая объясняет, как его использовать. Надеюсь, это поможет тебе, парень.

Emacs Server

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.