Có bất kỳ nhược điểm nào khi đặt `gc-cons-ngưỡng` rất cao và thu gom rác khi không sử dụng không?

Tôi đã thêm hai dòng sau vào đầu của tôi init.el:

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

Điều đó có nghĩa là thay vì thu gom rác cứ sau 800kb bộ nhớ được phân bổ, Emacs làm như vậy khi không hoạt động, tức là khi tạm dừng không làm phiền tôi. (Nó cũng thu thập sau khi phân bổ 1GB bộ nhớ, nhưng tôi không nghĩ điều đó sẽ xảy ra).

Điều này đã cải thiện thời gian khởi động của tôi khoảng hai phần ba. Về lý thuyết, nó cũng nên cải thiện hiệu suất nói chung. Có bất kỳ nhược điểm của phương pháp này?

start-up performance garbage-collect

— Erik
nguồn

Về nguyên tắc, bạn không nên đặt gc-cons-thresholdcao hơn mức bạn sẵn sàng thực sự đạt được tại bất kỳ thời điểm nào, bởi vì bạn phải giả định rằng bạn sẽ thực sự đạt được giá trị đó theo thời gian (sau tất cả, ai biết được có thể tích lũy bao nhiêu rác bởi một số nhiệm vụ không nhàn rỗi bất ngờ nhiệt tình). Tôi không thấy một vấn đề cụ thể nào khi kích hoạt gc với bộ đếm thời gian nhàn rỗi, nhưng tôi nghĩ rằng việc đặt ngưỡng cho gc không nhàn rỗi cao như điều này có vẻ như OTT và ấn tượng của tôi là giá trị có thể được chọn là "cao hơn tôi sẽ không bao giờ cần "thay vì" cao nhất tôi sẵn sàng sử dụng ".

— phils

Theo bài đăng này của Stefan Monnier : "Tốt hơn đừng chạm vào nó. Trong Emacs-22, chúng tôi đã giới thiệu gc-cons-Perc mang lại lợi ích tương tự như tăng gc-cons-ngưỡng nhưng không có nhược điểm. Và không cần phải sử dụng nó. Tức là tôi khuyên người dùng nên xóa mọi cài đặt ngưỡng gc-cons-cons khỏi .emacs của họ. "

— izkon

@izkon ngoại trừ bài đăng bạn liên kết có từ năm 2007, trong khi ví dụ bài đăng này , nơi một người thực sự đã thử nghiệm - và thay đổi ngưỡng đã tạo ra sự khác biệt - bắt đầu từ năm 2016. Vì vậy, nó đã bị thoái lui hoặc cách giải quyết chưa bao giờ làm việc tốt.

— Hi-Angel

@Erik Tôi nghĩ bạn có thể thay thế (eval-when-compile (* 1024 1024 1024))bằng most-positive-fixnum (vui lòng làm như vậy, tôi khá chắc chắn rằng mọi người gặp câu hỏi của bạn đều sao chép mã của bạn vào cấu hình của họ) .

— Hi-Angel

@ Hi-Angel Tôi không nghĩ đó là một ý tưởng tốt. Nếu Emacs thực sự phân bổ số lượng lớn bộ nhớ mà không bị nhàn rỗi, thì gc thay vì tiếp tục phân bổ cho đến khi hệ thống phải trao đổi hoặc thậm chí hết bộ nhớ. Nếu bất cứ điều gì, 1GB đã quá cao.

— Erik

Theo như tôi biết, nếu bạn có RAM, thì không sao, nhưng nếu Emacs từng đạt mức sử dụng thực sự cao trước khi sử dụng GC, thì có thể sẽ mất nhiều thời gian. Tôi không chắc chính xác Eli nghĩa là gì; ISTM rằng nếu bạn có đủ bộ nhớ, nó sẽ ổn thôi, nhưng anh ấy là chuyên gia ở đây.

Phải nói rằng, tôi đã sử dụng những dòng này trong tệp init của mình một thời gian rồi và nó giúp giảm thời gian khởi động mà không làm thay đổi vĩnh viễn:

;;;;; 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")))

— blujay
nguồn

Tại sao bạn không sử dụng after-init-hook?

— Erik

Bởi vì điều đó sẽ chạy ngay sau khi khởi tạo, điều này có thể khiến người dùng chờ đợi GC. Bằng cách sử dụng bộ đếm thời gian nhàn rỗi, nó có thể chạy khi người dùng không sử dụng Emacs.

— blujay