Việc đặt các phần tử đồng nhất vào một cấu trúc dữ liệu, sau đó dùng con trỏ duyệt (iterator) để xử lý từng phần tử là một yêu cầu phổ biến trong lập trình. Tuy nhiên, quá trình này tiềm ẩn nhiều rủi ro gây ra lỗi hệ thống. Vấn đề nằm ở tính nguyên tử (atomicity) — khi vừa duyệt vừa thay đổi cấu trúc dữ liệu, hai thao tác này gần như không thể xảy ra đồng thời một cách an toàn.
Vào cuối tuần trước, một đồng nghiệp đã đặt câu hỏi với tôi về việc họ nghi ngờ quá trình thu gom rác (GC) của Lua đang gây ra chi phí hệ thống quá lớn trong hệ thống của họ. Đặc biệt, một phần chi phí này dường như không cần thiết.
Trong hệ thống của họ, có một lượng lớn dữ liệu cấu trúc chỉ đọc, không liên quan đến các dữ liệu khác - chủ yếu là các tham số logic trò chơi do策划设定 (cần dịch lại thành “nhóm thiết kế trò chơi” hoặc “nhóm策划” tùy ngữ cảnh). Những dữ liệu này có cấu trúc phức tạp, dẫn đến việc trình thu gom rác phải duyệt qua rất nhiều đối tượng trong quá trình hoạt động. Tuy nhiên, rõ ràng chúng ta đều biết rằng những dữ liệu này sẽ không bao giờ bị thu hồi, đồng thời cũng không ảnh hưởng đến kết quả của quá trình GC. Vậy liệu có cách nào để tối ưu hóa vấn đề này?
Vấn đề xử lý dấu gạch chéo ngược trong GNU Make
GNU Make có cách xử lý dấu gạch chéo ngược () vô cùng phiền phức. Nếu dùng phương pháp thông thường, bạn gần như không thể tạo ra một dấu \ đơn lẻ.
Ví dụ, nếu bạn viết trực tiếp SLASH = \ thì sẽ không thành công, bởi vì \ được dùng để nối dòng tiếp theo.
Còn khi dùng SLASH = \ thì lại tạo ra hai dấu gạch chéo ngược thay vì một.
Dưới đây là phiên bản viết lại bằng tiếng Việt phong phú và chi tiết, giữ nguyên ý nghĩa nhưng diễn đạt theo cách khác và bổ sung thêm nội dung:
Hôm nay mình muốn chia sẻ cách tối ưu hóa file Makefile trong dự án bằng cách di chuyển các tệp trung gian như .o (object file) và .a (static library) vào một thư mục độc lập. Trong quá trình thực hiện, mình đã gặp phải một số vấn đề thú vị liên quan đến cách GNU Make xử lý đường dẫn và quy tắc phụ thuộc.
Trên blog của Lưu Vị Bằng có bài viết “Nguyên tắc cốt lõi của lập trình (s) là gì?” đang được chia sẻ rộng rãi trên Google Reader những ngày qua. Điều này khiến tôi tự hỏi: Nguyên tắc hàng đầu mà bản thân đang theo đuổi là gì?
Thực ra những điều tôi muốn nói đều đã có người đề cập trong bài viết đó. Nếu phải chọn một nguyên tắc tối thượng, tôi đồng tình với đa số khi chọn KISS - Hãy giữ mọi thứ đơn giản, đừng phức tạp hóa. Tuy nhiên, với nguyên tắc DRY - Đừng lặp lại chính mình (Don’t Repeat Yourself), tôi lại cho rằng nó chỉ nên xếp thứ yếu, đặc biệt khi va chạm với KISS.
Hôm nay bất ngờ phát hiện bạn darkdestiny năm ngoái đã viết một loạt bài phân tích mã nguồn về “manual GC” rất chi tiết :D
Trước hết phải cảm phục bạn ấy vì đã kiên nhẫn đọc xong đoạn mã rối mắt này - thật sự mà nói, đây là một phần code mà ngay cả bản thân tôi khi nhìn lại cũng phải giật mình vì sự lộn xộn của nó.
Chuyện thu gom rác (A)
Đây là bài đầu tiên trong chuỗi từ A đến K, các bạn quan tâm hãy tự tìm đọc các phần tiếp theo nhé.
Phải thành thật thừa nhận rằng hàm cache_flush chính là đoạn code tệ nhất trong toàn bộ thư viện này. Đúng là khi viết xong bản nháp đầu tiên, tôi cũng có ý định tổ chức lại cho sạch sẽ hơn, nhưng càng tối ưu lại càng rối. Đây cũng chính là lý do khiến tôi ngần ngại chưa dám open-source nhiều dự án khác.