Çok uzun çizgilerin Emac'leri yavaşlatmasını nasıl önlerim?

Ziyaret ettiğim dosyada kaç tane yeni satır olduğuna bağlı olarak oldukça farklı performanslar görüyorum.

İşte bir örnek. İki JSON dosyam var:

$ 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

Bunlar aynı içeriğe sahip iki JSON dosyasıdır. one_line.json189 MB of JSON. pretty_printed.jsonyeni satırları ve boşlukları ekledi, 41MiB yapıyor.

Bununla birlikte, birçok satıra bölünmüş daha büyük dosya, hem Javascript modunda hem de Temel modda, Emacs'ta açmak için çok daha hızlıdır.

Emac'lar neden aslında daha az bayt olduğundan uzun çizgilerle bu kadar düşük performans gösteriyor? Emacs dışındaki verileri yeniden biçimlendirmeden performansı iyileştirmek için yapabileceğim bir şey var mı?

Emacs'in uzun hatları kullanması pek iyi bir şekilde optimize edilmemiştir. Bir dizi işlem için, Emacs tüm çizgiyi tekrar tekrar taramak zorundadır. Örneğin, bir çizgi görüntülemek için Emacs, en uzun glifi bulmak için tüm çizgiyi taramayı gerektiren çizginin yüksekliğini bulmak zorundadır. Ek olarak, iki yönlü ekran taraması çok fazla zaman alır. Örneğin, ek belgelerine ek bilgi alabilirsiniz cache-long-line-scans( cache-long-scans24.4'te yeniden adlandırılmıştır ).

Sen denemek ve ayar olmadığını görebilirsiniz bidi-paragraph-directioniçin left-to-right[ayarı sizin için hızını artırır bidi-display-reorderingiçin nil, aşağı yukarı aynı yapar ama iç / hata ayıklama amacıyla sadece içindir]. Bu, çizgi taramalarına önemli bir katkıda bulunanı kaldırıyor, ancak ne yazık ki yalnızca biri değil.

En iyi seçenek yeni satırlar eklemektir. Bir JSON dosyasını örneğin python -c 'import json, sys ; json.dump(json.load(sys.stdin), sys.stdout, indent=2)'yeni hatlar eklemek ve genel olarak okunabilirliği artırmak için aracılığıyla yönlendirebilirsiniz .

Küçük bir jquery kopyası kullanarak bununla ilgili kısa deneyler yaptım. font-lock-modeve flycheck-modeher ikisi de yaptığı gibi, yavaşlık katkıda js2-modeve prettify-symbols-mode. line-number-modeve column-number-modeküçük etkisi oldu. Bir keresinde performans nispeten çabuk olmasına rağmen farklı modları kapatmıştım. C-h mEtkinleştirilen farklı modları devre dışı bırakmayı kullanın ve başlayın ya da sadece geçiş yapmayı deneyin fundamental-mode.

İlginçtir hexl-modeki, sütunlar oldukça kısa olmasına rağmen, dosya kullanarak herhangi bir sorun olmadan uçabiliyordum. Ne yazık ki visual-line-modegerçekten işleri yavaşlattı.

Tahminim, sözdizimi tablosunun satır sonlarında işlemeyi durdurmaktan mutlu olduğu ve her satırda bir satırda işlem yaptığı her güncellemede her şeyi yeniden doldurması gerektiğidir.

Http://www.emacswiki.org/emacs/OverLongLineMode dosyasını yükledim

Bu kütüphane, fundamental-modenormal modu yerine bir dosya için bir değişkenin kullanılacağı basit çizgi uzunluğu eşiklerini ayarlamanızı sağlar (yalnızca programlama modları için).

Potansiyel olarak bu satırlar boyunca bir şey varsayılan olarak Emacs'a eklenebilir, ancak bu, Emacs'in birincil sorusu için böyle bir dosyayla karşılaştığında sürünerek yavaşlayan geçici bir çözüm olabilir.

nb Bu, başlangıçta bu cevapta gönderdiğim koddaki bir gelişmedir, ancak halen devam etmekte olan bir çalışmadır. Test çok az olmuştur. Yorumlarınızı bekliyoruz.

Diğer (yanı sıra css-mode) prog-modevarsayılan olarak desteklenmek üzere onaylanmamış ana modlar için öneriler de memnuniyetle karşılanmaktadır.

Aradaki farkın sebebini bulacağınızı umuyorum font-lock. Pencerede görülebilen dosyanın alt kümesinde fontifikasyon yapılacaksa, ilk önce fontlaşma bölgesini tam anlamsal birimler içerecek şekilde genişleterek devam eder. Bunun için font-lock-extend-region-functionskoda bakınız . Bunun, bölgenin tam çizgiler içerecek şekilde genişletilmesini içermesi yaygındır. Çizgiler aşırı uzun olduğunda, bu, fontların gerçekten göründüğünden çok daha büyük bir içerik yığınında gerçekleştirilmesine neden olabilir.

Ek olarak, yeni satırların kendileri anlamsal bilgilere sahip olduğunda, bunların yokluğu bazen yazı tipi kilidi için regexp kalıplarının eşleşip eşleşmediklerini belirlemek için daha fazla taraması gerektiği anlamına gelebilir.

Genellikle uzun satırları kaldırırım ve etiketlere göre girinti (HTML, XML, JSON gibi).

Böyle bir işlemi mümkün kılmak için şunu ekliyorum:

(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))

Ben XML bunu için, regex satır bölünmüş: C-M-% >< RET >NL< RET !.

Emacs uzun çizgiler ayırdıktan sonra - birçok *-modeskodu tekrar girip tekrar girintiyi girebilirsiniz.

Not için: Düşük kaliteli işlemler uzun çizgiler oluştururken yavaşlama nasıl önlenir?

Burada bu sorun için kendi çözümümü oluşturdum: https://github.com/rakete/too-long-lines-mode

Çok uzun çizgilerden oluşan bir tamponu temel moda geçiren phils çözümünden memnun kalmadım, sözdizimi vurgulamasını ve diğer ana mod özelliklerini korumamı sağlayan bir çözüm istedim. Bu yüzden aşırı uzun çizgilerin çoğu karakterini gizlemek için bindirmeleri kullanan küçük bir mod yarattım.

Bu sorun etrafında çalışır ve temel moda geri dönmek zorunda kalmadan, çok uzun çizgileri olan tamponlarda bile amacları kullanılabilir hale getirir.

Emac kurulumumda, özel fontlandırmaya sahip bir modum var, yani belirlediğim yerde font-lock-defaults. Tek bir sayfa aşağı 30000 karakter satırının bir kısmını görüntülemek için 30 saniye kullanır. Bu yavaşlama, regexp geri izlemesini azaltarak giderildi. Onun yerine:

  (". * tamamlanmamış bir komutla sona erdi *" 0 font-lock-comment-face)

Bunu yap

  ("^. \ {1,80 \} eksik bir komutla sona erdi *" 0 font-lock-comment-face)

Kabuk modu tamponlarımda (Mx kabuğu), sed -r 's/(.{2000}).*/\1/' -uuzun çizgilerden kaçınmak için kendimi borular buluyorum .

dired-modeUzun satırlı büyük dosyaları açmak için aşağıdaki işlevi kullanıyorum :

(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)

İşte emacs-devel'den alınan bir geçici çözüm :

(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)))))