Vì sao các ngôn ngữ lập trình động dùng "shape" thay vì bảng băm để lưu thuộc tính?

Trong phần lớn các ngôn ngữ lập trình kiểu động, một đối tượng trông chẳng khác gì một bảng ánh xạ từ tên sang giá trị. Chính sự linh hoạt này khiến người viết runtime dễ nghĩ tới việc dùng bảng băm để lưu thuộc tính. Nhưng cách làm ngây thơ đó khiến mỗi phép a.b tiêu tốn hàng trăm, thậm chí hàng nghìn lệnh CPU. Đó là lý do các runtime thực tế dùng một cấu trúc gọi là map, shape, layout hay hidden class — và bài viết dưới đây giúp bạn hiểu cơ chế này chỉ trong một trang code.

Vấn đề: bảng băm không miễn phí

Ở các ngôn ngữ như Python, đối tượng được thiết kế để có thể thêm hay bớt thuộc tính bất cứ lúc nào. Mô hình trực quan nhất là lưu thuộc tính trong một hash table: tra tên, lấy giá trị. Nhưng mỗi lần tra cứu là nhiều lần nạp bộ nhớ phụ thuộc nhau, và trong một vòng lặp nóng thì chi phí đó nhân lên rất nhanh.

• Mỗi lần đọc/ghi thuộc tính phải băm chuỗi tên.
• Phải dò trong bảng, xử lý va chạm.
• Các lần truy cập bộ nhớ có tính phụ thuộc, khó tận dụng cache CPU.

Shape giải quyết điều gì?

Ý tưởng cốt lõi là tách bố cục bộ nhớ của đối tượng ra khỏi dữ liệu của nó. Mỗi đối tượng giữ một con trỏ tới một shape mô tả: đối tượng có những thuộc tính nào, và mỗi thuộc tính nằm ở độ lệch (offset) nào so với đầu đối tượng. Shape đóng ba vai trò:

• Chỉ mục: trả lời câu hỏi "thuộc tính này nằm ở đâu?".
• Không đổi (immutable): khi thêm thuộc tính, ta tạo shape mới thay vì sửa shape cũ. Nhờ vậy chỉ cần so sánh con trỏ là biết bố cục có đổi hay không.
• Định danh ổn định: cùng một bố cục luôn ứng với cùng một shape.

Shape thường được tổ chức thành cây (kiểu trie) và cấp phát như một cấu trúc dữ liệu bền vững. Mọi đối tượng khởi đầu với shape rỗng; khi chương trình thêm thuộc tính, nó đi theo các cạnh của cây để tìm hoặc tạo shape mới.

Điểm mấu chốt: nếu đã biết offset, ta đọc thẳng từ đối tượng, không cần tra bảng lần nữa. Ta đã cầm đối tượng trong tay, và nhiều khả năng nó đã nằm sẵn trong cache.

Inline cache: nơi phép màu thực sự xảy ra

Lợi ích của shape chỉ hiện thực hóa khi ta nhớ lại offset từ lần tra trước. Cơ chế này có tên là inline cache (IC). Trong bytecode, tên thuộc tính thường là hằng số (LOAD_ATTRIBUTE "x"), nên IC có thể lưu cặp (shape mong đợi, offset đã cache) ngay tại điểm gọi.

Khi chạy, IC thực hiện:

• Kiểm tra cực nhanh: shape hiện tại của đối tượng có trùng với shape đã cache không? Phép so sánh dùng so sánh con trỏ, không phải so sánh sâu.
• Nếu trùng: đọc theo offset đã biết — rất nhanh.
• Nếu lệch: đi đường chậm, tra cứu lại và (thường) cập nhật cache.

Đây là lý do shape phải bất biến: chỉ khi đó ta mới dám tin rằng so sánh con trỏ là đủ. Trong Python, tác giả mô phỏng IC bằng một lớp InlineCache đơn giản; trong runtime thật, đường nhanh được inline còn đường chậm được tách ra ngoài, và thường được JIT biên dịch để loại bỏ hoàn toàn phần "thông dịch" của IC.

Thứ tự khởi tạo thuộc tính quan trọng hơn bạn tưởng

Một hệ quả dễ bị bỏ qua: thứ tự thêm thuộc tính tạo ra shape khác nhau. Gán a rồi b cho ra shape khác với gán b rồi a. Việc gán thuộc tính có điều kiện trong hàm khởi tạo (ví dụ if cond: self.a = 1) cũng tạo shape khác nhau tùy nhánh.

Điều này ảnh hưởng trực tiếp tới hiệu năng:

• IC bị miss thường xuyên, hoặc rơi vào trạng thái đa hình (polymorphic) thay vì đơn hình (monomorphic).
• Trong đường nóng, chênh lệch giữa hit và miss có thể lên tới gấp đôi hiệu năng hoặc hơn.

Lời khuyên thực dụng cho lập trình viên là giữ cho các đối tượng cùng loại có bố cục nhất quán. Cộng đồng Ruby từng có những PR lớn chỉ để làm shape đơn hình hơn, kể cả khi JIT xử lý được shape đa hình — vì lợi ích lan sang mọi JIT khác.

Số lượng thuộc tính cũng có giới hạn

Các kỹ sư runtime đã đo và nhận thấy phần lớn đối tượng có ít trường (dưới khoảng 20). Nhồi quá nhiều trường có thể khiến đối tượng bị "phạt" và quay về chế độ bảng băm. Chẳng hạn Ruby có một số biến instance cố định nằm trong đối tượng; vượt ngưỡng đó, shape chuyển sang dạng "phức tạp" và chậm hơn.

Shape không nhất thiết gắn với class

Một điểm thú vị: hai đối tượng thuộc hai class khác nhau vẫn có thể chia sẻ cùng một shape. Điều này có mặt tốt và mặt xấu.

• Tốt: tỉ lệ hit của IC cao hơn. Các instance của lớp con dùng chung code có thể vẫn được tính là đơn hình.
• Xấu: không thể dùng shape để suy ra class. Nếu runtime cần sinh phương thức tra cứu biến instance (như attr_reader của Ruby), nó phải tra hai bước: shape → offset, rồi offset → class. Hai bước này tốn cả độ phức tạp lẫn thời gian chạy.

Nếu gắn class vào shape, ta có thể gộp hai bước thành một lần nạp trường. Đây là hướng mở rộng đáng thử: còn có thể chuyên biệt hóa shape theo những gì khác nữa?

Mở rộng: kiểu dữ liệu và "đóng băng kiểu"

Bài báo Storage Strategies for Collections in Dynamically Typed Languages (2013) của CF Bolz-Tereick cùng Lukas Diekmann và Laurence Tratt chỉ ra rằng một số đặc điểm về đối tượng vừa quan trọng với bộ tối ưu hóa, vừa hiếm khi thay đổi. Áp dụng cho collection: tối ưu trường hợp danh sách rỗng hay danh sách số nguyên nhỏ giúp giảm cả bộ nhớ lẫn số lần đuổi con trỏ.

Tư duy tương tự dẫn tới Type Freezing (2020): biến map từ {tên: offset} thành {tên: (offset, kiểu)} để giảm số guard trong JIT. Nếu lớp Point của bạn luôn chứa số thực ở một trường, runtime có thể đặt cược vào điều đó.

Trong runtime thật: bố cục bộ nhớ ra sao?

Khi viết bằng C++ hay Rust, thuộc tính thường được cấp phát liền kề (inline) với phần đầu đối tượng, không nằm trong một vùng nhớ tách rời như bản mô phỏng bằng Python. Các runtime lớn như V8, JavaScriptCore hay Skybison có:

• Header đối tượng gọn, chứa con trỏ shape và vài bit cờ.
• Vùng lưu thuộc tính nằm ngay sau header.
• Một ô tràn (overflow) cho trường hợp ước lượng kích thước ban đầu quá nhỏ.

Tác giả đã dựng thử một runtime tí hon bằng C++ để phác họa mô hình bộ nhớ này. Nó chưa có ô tràn và chắc chắn còn lỗi, nhưng đủ để thấy nền tảng chung của những engine hàng đầu hiện nay.

Góc nhìn cho lập trình viên Việt Nam

Với các bạn làm backend Python, Ruby hay JavaScript, những chi tiết này không chỉ là chuyện nội bộ của engine. Chúng giải thích vì sao việc khởi tạo đối tượng thiếu nhất quán — đặc biệt khi làm việc với ORM, model hay DTO lớn — lại có thể âm thầm kéo hiệu năng xuống. Vài thói quen nhỏ giúp ích:

• Khởi tạo đủ thuộc tính trong __init__/constructor theo thứ tự cố định.
• Tránh thêm thuộc tính tùy tiện ở nhiều nơi trong vòng đời đối tượng.
• Giữ đối tượng gọn; tách bớt trường không cần thiết.
• Khi nghi ngờ, hãy đo bằng benchmark thay vì đoán.

Bài viết gốc vẫn còn dang dở — tác giả dự định thêm shape và inline cache vào một trình thông dịch Lox. Nhưng ngay với những gì đã có, ta đã nắm được vì sao một cấu trúc tưởng như "đổi bảng băm này lấy bảng băm khác" lại là một trong những tối ưu quan trọng bậc nhất của các ngôn ngữ động hiện đại.