Подтвердить что ты не робот

Emacs 23.1.50.1 висит ramdomly в течение 6-8 секунд в Windows XP

У меня есть EmacsW32 23.1.50.1 emacs, работающий на моем компьютере с Windows XP. Он зависает случайным образом от 5 до 8 секунд и довольно расстраивает.

У любого есть решение?

Я даже пытался использовать emacs win32 двоичные файлы (23.1) с сайта gnu ftp, а также зависает в течение нескольких секунд.

Здесь некоторые заметные журналы журналов процессов

10: 56: 59.9888359 PM CreateFile C:\usr\spool\mail\ PATH NOT FOUND Желаемый доступ: чтение каталога данных/списка, синхронизация, расстановка:, Опции: Directory, Synchronous IO Non-Alert, Атрибуты: n/a, ShareMode: Чтение, Запись, РаспределениеSize: n/a

10: 57: 55.5073038 PM QueryAllInformationFile C:\emacs.emacs.d\auto-save-list ОБНОВЛЕНИЕ БУФЕРА CreationTime: 8/27/2009 12:51: 26 PM, LastAccessTime: 1/5/2010 10:54:40 PM, LastWriteTime: 1/5/2010 10:08:15 PM, ChangeTime: 1/5/2010 10:08:15 PM, FileAttributes: D, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: False, Directory: True, IndexNumber: 0x1000000001f702, EaSize: 0, Доступ: Чтение атрибутов, Синхронизация, Позиция: 0, Режим: Синхронный IO Non-Alert, AlignmentRequirement: Word

4b9b3361

Ответ 1

У меня была точно такая же проблема с использованием EmacsW32 23.1.50 на WinXP. Одно изменение, которое я сделал, которое значительно улучшило (для меня в любом случае), должно было добавить следующее в мой файл .emacs:

; try to improve slow performance on windows.
(setq w32-get-true-file-attributes nil)

Кажется, что эта переменная была изменена по умолчанию на "истина" относительно недавно и, как известно, вызывает некоторые проблемы с замедлением при доступе к файлу. Я все равно иногда получаю случайные зависания (возможно, из-за моих настроек .emacs), но теперь это намного лучше.

Ответ 2

Попробуйте остановить службу Netlogon в панели управления "Услуги". Это решило проблему в моем случае. См. Отличную статью http://www.hydrus.org.uk/journal/emacs-netlogon.html, которая спасла меня от агонии.

Это относится только к небольшой (но увеличивающейся?) группе пользователей, которая:

  • использовать корпоративную версию ноутбука
  • использовать окна 7
  • использовать emacs для редактора R
  • внезапно увидит, что ее emacs работают очень медленно.

Ответ 3

У меня были подобные проблемы, и я проследил его по сетевым тайм-аутам в Windows. В моем конкретном случае это произошло из-за ido.el, который хранит кешированный список содержимого каталога. При запуске ido пытался проверить кэшированные каталоги, которые включали сетевые ресурсы как в моей домашней сети, так и в моей рабочей сети - всегда существовали несуществующие хосты, независимо от того, в какой сети я был.

Поскольку моя проблема возникла с помощью ido (вроде), решение для меня состояло в том, чтобы установить ido-max-dir-file-cache в 0 (через customize-variable или init.el), затем выйти из Emacs, удалить ~/.emacs.d/.ido.last и перезапустить Emacs. Основываясь на том, что я видел в другом потоке, важно убедиться, что все экземпляры Emacs закрыты, прежде чем пытаться удалить .ido.last. Могут быть другие переменные ido, которые необходимо изменить, но до сих пор это решение работает для меня.

Ответ 4

Без отладочного вывода будет сложно сказать, что вызывает задержку.

Поскольку задержки часто вызваны таймаутами IO, я рекомендую запустить Process Monitor, чтобы узнать, что делает Emacs во время его висячего.

Ответ 5

У меня есть окна 7, это происходило со мной, потому что я использовал классический интерфейс Windows, после того, как я изменил тему по умолчанию, она отлично работала, возможно, и сервис Themes имеет какое-то отношение к этому, поэтому, если вы его остановите, попробуйте запустив его.

Ответ 6

После отключения режима global-auto-revert, система делает гораздо меньше ввода-вывода. Для меня это, похоже, решило проблему.

Ответ 7

Это связано с отключением ответа netlogon. Оказалось, что отключение netlogon давало мне проблемы с сетевыми дисками, поэтому было неприятно его отключать. Я обнаружил, что долгое время я переключил свои DNS, предоставленные в google public dns. Это оказывается очень плохой идеей в корпоративном домене. Я переключил его обратно на автоматическое обнаружение dns, и проблема исчезла.