Як запобігти надзвичайно довгим лініям робити Emacs повільним?

Я бачу надзвичайно різну продуктивність залежно від кількості нових рядків у файлі, який я відвідую.

Ось приклад. У мене є два файли JSON:

$ wget https://github.com/Wilfred/ReVo-utilities/blob/a4bdc40dd2656c496defc461fc19c403c8306d9f/revo-export/dictionary.json?raw=true -O one_line.json
$ python -m json.tool <one_line.json >pretty_printed.json

Це два файли JSON з однаковим вмістом. one_line.jsonстановить 18 Мбіт JSON без будь-яких нових рядків. pretty_printed.jsonдодано нові рядки та пробіли, що робить його 41MiB.

Однак більший розділений файл на багато рядків набагато швидше відкриється в Emacs, як в режимі Javascript, так і в основному.

Чому Emacs має таку низьку продуктивність із довгими рядками, оскільки насправді менше байтів? Чи можу я щось зробити для підвищення продуктивності без переформатування даних поза Emacs?

Робота з довгими лініями Emacs не дуже оптимізована. Для ряду операцій Emacs має повторно сканувати всю лінію. Наприклад, щоб відобразити лінію, Emacs має визначити висоту лінії, що вимагає сканування всієї лінії, щоб знайти найвищий гліф. Крім того, сканування двонаправленого дисплея з'їдає багато часу. Ви можете отримати додаткову інформацію в, наприклад, доктрині cache-long-line-scans(перейменованому cache-long-scansв 24.4).

Ви можете спробувати і подивитися , якщо установка bidi-paragraph-directionдля left-to-rightпокращує швидкість для вас [призахідного bidi-display-reorderingдо nil, робить більш-менш те ж саме , але призначений тільки для внутрішніх цілей / налагодження]. Це видаляє одного істотного учасника сканування рядків, але, на жаль, не єдиного.

Найкращий варіант - додавання нових рядків. Ви можете передавати файл JSON через, наприклад, python -c 'import json, sys ; json.dump(json.load(sys.stdin), sys.stdout, indent=2)'для додавання нових рядків та покращення читабельності в цілому.

Я зробив кілька коротких експериментів з цим, використовуючи мінімізовану копію jquery. font-lock-modeі flycheck-modeобидва сприяли повільності, як js2-modeі prettify-symbols-mode. line-number-modeі column-number-modeмала незначну дію. Одного разу я вимкнув усі різні режими, хоча продуктивність була досить швидкою. Використовуйте C-h mта починайте відключати різні включені режими або спробуйте просто перейти на fundamental-mode.

Цікаво, що за допомогою hexl-modeя міг пролетіти через файл без жодних проблем, хоча очевидно колонки були досить короткими. На жаль, visual-line-modeсправді сповільнили справи.

Я здогадуюсь, що синтаксична таблиця рада зупинити обробку в кінцях рядка, і коли вона знаходиться в одному рядку, вона повинна переглядати все під час кожного оновлення.

Я завантажив http://www.emacswiki.org/emacs/OverLongLineMode

Ця бібліотека дозволяє встановити прості пороги довжини рядка, понад які варіант fundamental-modeфайлу буде використовуватися для файлу замість його звичайного режиму (лише для режимів програмування).

Потенційно щось за цими рядками може бути додане до Emacs за замовчуванням, але це може бути тимчасовим вирішенням первинної проблеми, що Emacs сповільнюється до повзання при зустрічі з таким файлом.

nb Це вдосконалення щодо коду, який я спочатку розміщував у цій відповіді, але все ще незавершений. Тестування було мінімальним. Коментарі вітаються.

Запропоновані пропозиції щодо інших (крім css-mode) prog-modeосновних режимів, які не використовуються для підтримки за замовчуванням.

Я сподіваюся, що ви побачите, що різниця пов'язана з font-lock. Коли fontification повинен бути виконаний на підмножині файлу, який є видимим у вікні, він продовжується, спочатку розширивши область fontification таким чином, що вона буде включати повні семантичні одиниці. Дивіться font-lock-extend-region-functionsкод для цього. Для цього прийнято включати розширення регіону на повний рядок. Коли рядки надзвичайно довгі, це може призвести до того, що фентифікація буде виконана на значно більшій частині вмісту, ніж насправді видно.

Крім того, коли у самих нових рядках є семантична інформація, їх відсутність іноді може означати, що шаблони повторного вимикання блокування шрифту повинні додатково сканувати, щоб визначити, чи відповідають вони чи ні.

Зазвичай я розкручую довгі рядки та відступи тегами (наприклад, HTML, XML, JSON).

Для того, щоб зробити таку операцію можливою, я додаю:

(setq line-number-display-limit large-file-warning-threshold)
(setq line-number-display-limit-width 200)

(defun my--is-file-large ()
  "If buffer too large and my cause performance issue."
  (< large-file-warning-threshold (buffer-size)))

(define-derived-mode my-large-file-mode fundamental-mode "LargeFile"
  "Fixes performance issues in Emacs for large files."
  ;; (setq buffer-read-only t)
  (setq bidi-display-reordering nil)
  (jit-lock-mode nil)
  (buffer-disable-undo)
  (set (make-variable-buffer-local 'global-hl-line-mode) nil)
  (set (make-variable-buffer-local 'line-number-mode) nil)
  (set (make-variable-buffer-local 'column-number-mode) nil) )

(add-to-list 'magic-mode-alist (cons #'my--is-file-large #'my-large-file-mode))

Я розділив лінію регулярних виразів для XML цього: C-M-% >< RET >NL< RET !.

Після того, як Emacs розділив довгі рядки - можна ввімкнути багато *-modesі повторно відступити код.

Для примітки: Як запобігти уповільнення, коли неповноцінні процеси генерують довгі лінії?

Я створив власне рішення цієї проблеми тут: https://github.com/rakete/too-long-lines-mode

Мене не влаштовує рішення phils, яке перемикає буфер з дуже довгими рядками на основний режим, я хотів рішення, яке дозволяє мені зберігати підсвічування синтаксису та інші функції головного режиму. Тому я створив мінорний режим, який використовує накладки, щоб приховати більшість символів занадто довгих рядків.

Це вирішує проблему і робить emacs зручним для використання навіть у буферах з дуже довгими рядками, без необхідності повернутися до основного режиму.

У моєму налаштуванні Emacs у мене є режим із власною настройкою, тобто там, де я встановив font-lock-defaults. На одній сторінці вниз знадобиться 30 секунд, щоб відобразити частину 30000 символьних рядків. Це уповільнення було виправлено за рахунок зменшення зворотного відстеження. Замість:

  (". * закінчилося неповною командою *" 0 шрифт-блокування-коментар-обличчя)

зробити це

  ("^. \ {1,80 \} закінчився неповною командою *" 0 шрифт-замок-коментар-обличчя)

У своїх буферах оболонки в режимі оболонки (оболонка Mx) я опиняюсь так, sed -r 's/(.{2000}).*/\1/' -uщоб уникати довгих рядків.

Я використовую наступну функцію для відкриття у dired-modeвеликих файлах з довгими рядками:

(defun dired-find-file-conservatively ()
   (interactive)
   (let ((auto-mode-alist nil))
     (dired-find-file)
     ;; disable costly modes
     (fundamental-mode)
     (setq-local bidi-display-reordering nil)
     (when (boundp 'smartparens-mode)
       (smartparens-mode -1))))

(define-key dired-mode-map (kbd "S-<return>") 'dired-find-file-conservatively)

Ось вирішення, взяте з emacs-devel :

(add-hook 'find-file-hook
          (defun my-find-file-care-about-long-lines ()
            (save-excursion
              (goto-char (point-min))
              (when (and (not (eq major-mode 'image-mode))
                         (search-forward-regexp ".\\{2000\\}" 50000 t)
                         (y-or-n-p "Very long lines detected - enable 
longlines-mode? "))
                (require 'longlines)
                (longlines-mode +1)))))