Lời khuyên chung về giảm thời gian GC trong GHC

Question

Có bất kỳ quy tắc chung nào cần tuân theo để khám phá nguyên nhân khi chương trình do GHC biên soạn dành nhiều thời gian để thu gom rác thải không? Và những gì thường được coi là quá nhiều? Ví dụ, nói chung, 60% năng suất có thể chấp nhận được hay là một dấu hiệu cho thấy có thể có điều gì đó sai với mã?

Answer 1

Dưới đây là một danh sách nhanh chóng và rất không đầy đủ:

1. thử nghiệm và chuẩn mực. Một trong những điểm yếu của haskell là khó khăn trong việc dự đoán chi phí thời gian và không gian. Nếu bạn không có dữ liệu thử nghiệm thì bạn không có gì.
2. Sử dụng thuật toán tốt hơn. Điều này nghe có vẻ quá đơn giản, nhưng tối ưu hóa các thuật toán không hiệu quả giống như việc cắt s ** t bằng vàng.
3. Làm cho một số dữ liệu trở nên chặt chẽ hơn. Kiểm tra và điểm chuẩn! Mục đích là để lưu trữ giá trị WHNF nhỏ hơn về thể chất chứ không phải là thunk tạo ra nó, do đó làm sạch thêm rác trong lần chuyền đầu tiên hiệu quả nhất. tìm các hàm phức tạp tạo ra dữ liệu đơn giản.
4. Làm cho một số dữ liệu kém chặt chẽ hơn. Kiểm tra và điểm chuẩn! Mục tiêu là việc sản xuất chậm trễ một lượng lớn dữ liệu cho đến trước khi nó được sử dụng và bị loại bỏ, do đó làm sạch thêm rác trong lần chuyền đầu tiên hiệu quả nhất. Tìm các hàm đơn giản tạo ra dữ liệu phức tạp lớn. Xem thêm comonads.
5. Sử dụng chiến lược các mảng và các loại không được hộp, đặc biệt xem # 2. đối với đơn ST. Kiểm tra và điểm chuẩn! Tất cả các dữ liệu này phù hợp với nhiều dữ liệu thô hơn vào bộ nhớ nhỏ gọn hơn. Có ít rác để thu thập.
6. Fiddle với cài đặt RTS (ghc cụ thể). Kiểm tra và điểm chuẩn! Mục đích là để "trở kháng phù hợp" GC với nhu cầu bộ nhớ của chương trình của bạn. Tôi thậm chí còn mất nhiều hơn ở đây sau đó trong 1-5 để hỏi các chuyên gia về điều này.

Thu gom rác tốt hơn có tiền đề khá đơn giản: Tạo ít rác hơn, thu thập sớm hơn, tạo ít phân bổ bộ nhớ/deallocations hơn. Bất cứ điều gì bạn có thể làm điều đó có thể dẫn đến một trong ba hiệu ứng này đáng để bắn. Kiểm tra và điểm chuẩn!