Giới hạn kích thước thực tế của Hashtable và Từ điển trong c #


12

Các giới hạn thực tế cho số lượng mục mà Từ điển C # 4 hoặc Hashtable có thể chứa là gì và tổng số byte mà các cấu trúc này có thể chứa hợp lý. Tôi sẽ làm việc với số lượng lớn các đối tượng và muốn biết khi nào các cấu trúc này bắt đầu gặp sự cố.

Đối với ngữ cảnh, tôi sẽ sử dụng hệ thống 64 bit với hàng tấn bộ nhớ. Ngoài ra, tôi sẽ cần tìm các đối tượng bằng một số biểu mẫu hoặc 'khóa'. Với nhu cầu về hiệu năng, các đối tượng này sẽ cần nằm trong bộ nhớ và nhiều đối tượng sẽ tồn tại lâu dài.

Vui lòng đề xuất các cách tiếp cận / mẫu khác, mặc dù tôi cần tránh sử dụng các thư viện nguồn mở hoặc bên thứ ba. Vì lý do đặc điểm kỹ thuật, tôi cần có khả năng xây dựng điều này bằng cách sử dụng C # gốc ( hoặc C ++ \ CLI ).


1
Chỉ mất vài giờ hoặc hai giờ để mô phỏng và xử lý hiệu suất thêm / xóa / tra cứu theo các mức sử dụng / tải khác nhau. Tôi tin rằng VS2010 thậm chí còn cung cấp bộ xương thử nghiệm hiệu năng cho bạn. Bất kể ai nói gì ở đây, mã mà bạn sẽ viết sẽ có tên của bạn trên đó, trực tiếp hoặc trong siêu dữ liệu.
Công việc

Câu trả lời:


8

Một điều cần chỉ ra là Từ điển sẽ không giữ chính đối tượng (có thể có dung lượng bộ nhớ lớn) mà chỉ tham chiếu đến đối tượng nên nếu các đối tượng phức tạp thì điều này không ảnh hưởng đến kích thước Từ điển.

Tôi đã thu thập được hàng ngàn mục cùng nhau trong Từ điển trong bộ nhớ và vấn đề không phải là kích thước của Từ điển mà là kích thước của chính các đối tượng trong bộ nhớ. Trong những trường hợp này, từ điển là một phần nhỏ của bộ nhớ liên quan.

Một điều cần suy nghĩ trong các trường hợp của Từ điển lớn là cấu hình thủ công và quản lý dung lượng Từ điển. Trong các trường hợp thông thường .Net quản lý khoản tiền phạt này (trong triển khai hiện tại nếu hết dung lượng, nó sẽ thay đổi kích thước thành số nguyên tố ít nhất gấp đôi kích thước hiện tại của Từ điển). Tuy nhiên, nếu bạn biết bạn sẽ tạo một Từ điển lớn hoặc sẽ mở rộng Từ điển thay vì .Net đoán và thay đổi kích thước Từ điển cho bạn (tương đối tốn kém), có lẽ bạn nên tự làm điều này (chắc chắn với việc ban đầu kích thước và có thể quản lý thay đổi kích thước sau này). Điều này có thể được thực hiện bằng cách quản lý dung lượng Từ điển nếu bạn có ý tưởng heuristic hợp lý về năng lực của Từ điển. Microsoft khuyến nghị điều này trênMSDN trong nhận xét của họ về đối tượng Từ điển . Tuy nhiên, dường như có một số tranh luận về giá trị thực của phương pháp này mặc dù tôi không chắc thử nghiệm đó nghiêm ngặt đến mức nào và liệu có những tối ưu hóa khác mà nền tảng .Net đưa ra khi một từ điển thay đổi kích thước cực kỳ nhanh chóng.

Đây là một câu hỏi Stack Overflow hữu ích về kích thước đối tượng và bộ nhớ.


2

Các giới hạn thực tế có thể liên quan đến máy mà phần mềm của bạn đang chạy cũng như có bao nhiêu đối tượng bạn thực sự có kế hoạch chứa trong các cấu trúc dữ liệu này. Như Oded đã đề cập, int.MaxValue là một con số lớn, nhưng liệu 2 tỷ mặt hàng có tương đương với giới hạn thực tế không? Lưu trữ rằng nhiều mục trong bộ nhớ có thể không thực tế lắm.


0

Vì tài liệu không cho biết dữ liệu được lưu trữ ở đâu và nó không chỉ định giới hạn, tôi khuyên bạn nên thực hiện một thử nghiệm với kích thước tối đa dự kiến ​​mà bạn có thể có và lưu ý bộ nhớ hệ thống trước và sau khi phân bổ lưu trữ.


-1

Gần đây tôi đã cập nhật dự án băm bàn băm của dự án github (tại đây: https://github.com/jimbelton/hash-table-shootout ). Bản đồ không có gcc tiêu chuẩn có khoảng 1,8 GB tế bào để lưu trữ các đối tượng 40M. Điều này có vẻ khá tàn bạo đối với tôi, nhưng ngay cả bộ nhớ hoạt động tốt nhất, Google spzzy_hash_map, mất 600 Mbyte và bạn phải trả tiền phạt cho việc sử dụng nó. Nếu bạn muốn tốc độ, trong số các thuật toán được bao gồm, Glib GHashTable là tốc độ nhanh nhất và có hiệu suất bộ nhớ tốt (khoảng 1,3 Gbyte trên không). Kết quả điểm chuẩn được đăng tại đây: https://jimbelton.wordpress.com/2015/07/01/hash-table-shootout-on-github/

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.