Чи є якісь недоліки встановлення "gc-cons-limit" дуже високого рівня та збирання сміття в режимі очікування?


17

Я додав наступні два рядки до вершини мого init.el:

(setq gc-cons-threshold (eval-when-compile (* 1024 1024 1024)))
(run-with-idle-timer 2 t (lambda () (garbage-collect)))

Це означає, що замість того, щоб збирати сміття кожні 800 кб виділеної пам’яті, Emacs робить це в режимі очікування, тобто коли пауза не турбує мене. (Він також збирає після виділення 1 Гб пам'яті, але я не думаю, що це станеться).

Це покращило час мого запуску приблизно на дві третини. Теоретично це також повинно покращити продуктивність в цілому. Чи є якісь недоліки у цього підходу?


1
У принципі, ви не повинні встановлювати gc-cons-thresholdбільше, ніж ви готові насправді потрапити в будь-який момент часу, тому що ви повинні припустити, що ви будете реально вражати це значення час від часу (адже хто знає, скільки сміття може бути накопичено деяким несподівано захопленим непрацюючим завданням). Я не бачу особливої ​​проблеми із запуском gc з непрацюючим таймером, але я думаю, що встановити поріг для непрацюючого gc таким високим, як це здається OTT, і моє враження, що значення, ймовірно, було вибрано як "вище, ніж я Мені коли-небудь знадобиться », а не« найвищий, який я готовий використовувати ».
філс

5
Згідно з цим повідомленням Стефана Монньє : "Краще не торкайтеся цього. В Emacs-22 ми запровадили gc-мінус-відсоток, що забезпечує ту саму вигоду, що і підвищення gc-cons-порогу, але без недоліків. І без того, щоб з цим стикатися. Тобто я б рекомендував користувачам видаляти будь-які налаштування порогу gc-мінусу зі своїх .emacs. "
izkon

1
@izkon за винятком того, що публікація, з якою ви посилалися, датується 2007 роком, тоді як, наприклад, ця публікація , де хтось насправді експериментував - і зміна порогу змінила значення - датується 2016 роком. Отже, або вона регресувала, або спосіб вирішення просто ніколи добре працювали.
Привіт-Ангел

1
@Erik Я думаю , ви можете замінити (eval-when-compile (* 1024 1024 1024))з most-positive-fixnum (будь ласка , зробіть це, я впевнений , що все , хто попадається на ваше запитання копії коду в їх конфігурації) .
Привіт-Ангел

2
@ Привіт-Ангел Я не думаю, що це гарна ідея. Якщо Emacs насправді виділяє величезну кількість пам’яті, не стаючи в режимі очікування, вона повинна gc замість продовження виділення, поки системі не доведеться міняти місцями або навіть повністю не вичерпати пам'ять. Якщо що-небудь, 1 ГБ вже зависокий.
Ерік

Відповіді:


4

Наскільки я знаю, якщо у вас є оперативна пам’ять, це нормально, але якщо Emacs коли-небудь потрапляв до дуже високого використання перед GC'ing, це може зайняти багато часу. Я не впевнений, що саме означає Елі; ISTM, що якщо у вас достатньо пам'яті, це повинно бути добре, але він тут фахівець.

Сказавши це, я вже деякий час використовую ці рядки у своєму файлі init, і це допомагає скоротити час запуску без постійних змін:

;;;;; Startup optimizations

;;;;;; Set garbage collection threshold

;; From https://www.reddit.com/r/emacs/comments/3kqt6e/2_easy_little_known_steps_to_speed_up_emacs_start/

(setq gc-cons-threshold-original gc-cons-threshold)
(setq gc-cons-threshold (* 1024 1024 100))

;;;;;; Set file-name-handler-alist

;; Also from https://www.reddit.com/r/emacs/comments/3kqt6e/2_easy_little_known_steps_to_speed_up_emacs_start/

(setq file-name-handler-alist-original file-name-handler-alist)
(setq file-name-handler-alist nil)

;;;;;; Set deferred timer to reset them

(run-with-idle-timer
 5 nil
 (lambda ()
   (setq gc-cons-threshold gc-cons-threshold-original)
   (setq file-name-handler-alist file-name-handler-alist-original)
   (makunbound 'gc-cons-threshold-original)
   (makunbound 'file-name-handler-alist-original)
   (message "gc-cons-threshold and file-name-handler-alist restored")))

Чому ви не використовуєте after-init-hook?
Ерік

3
Тому що це запуститься відразу після ініціалізації, що може змусити користувача чекати GC. Використовуючи таймер очікування, він може працювати, коли користувач не використовує Emacs.
blujay
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.