So sánh hai đối tượng hơi lớn cho sự bình đẳng

Question

Tôi phải so sánh hai đối tượng lớn hơn để bình đẳng.

Thuộc tính của các đối tượng:

1. Chứa tất cả các thành viên của mình theo giá trị (vì vậy không gợi ý để làm theo).
2. Chúng cũng chứa một số stl::array.
3. Chúng chứa một số đối tượng khác giữ 1 và 2.
4. Kích thước tối đa một số kB.
5. Một số trong số members sẽ có nhiều khả năng khác hơn so với các loại khác, do đó dẫn đến ngắt nhanh hơn của thao tác so sánh nếu so sánh trước tiên.
6. Các đối tượng không thay đổi. Về cơ bản, thuật toán chỉ để đếm có bao nhiêu đối tượng giống nhau. Mỗi đối tượng chỉ được so sánh một lần với một số đối tượng "chính".

Cách tốt nhất để so sánh các đối tượng này là gì? Tôi thấy ba tùy chọn:

1. Chỉ cần sử dụng đơn giản, không quá tải operator==.
2. Quá tải == và thực hiện so sánh từng thành viên, bắt đầu với các thành viên có khả năng khác nhau.
3. Quá tải == và xem đối tượng dưới dạng trường byte thuần và so sánh từng từ.

Vài suy nghĩ:
Lựa chọn 1 dường như tốt vì nó có nghĩa là số tiền ít nhất của công việc (và cơ hội để giới thiệu lỗi).
Tùy chọn 2 có vẻ tốt, bởi vì tôi có thể khai thác phỏng đoán về yếu tố nào khác biệt nhiều nhất. Nhưng có lẽ nó vẫn còn chậm hơn vì được xây dựng trong == của tùy chọn 1 là ridiculously nhanh.
Lựa chọn 3 có vẻ là nhất "cấp thấp" tối ưu hóa, nhưng đó là những gì các trình biên dịch có lẽ cũng không cho tùy chọn 1.

Vì vậy, các câu hỏi là:

• Có một nổi tiếng cách tốt nhất để giải quyết nhiệm vụ?
• Có phải một trong các tùy chọn không tuyệt đối không?
• Tôi có phải cân nhắc điều gì khác không?

Answer 1

Một câu hỏi hay.

Nếu bạn có một số phỏng đoán về những thành viên nào có khả năng khác nhau - hãy sử dụng nó. Vì vậy, quá tải operator == và kiểm tra các thành viên nghi ngờ có vẻ là một ý tưởng hay.

Giới thiệu về so sánh byte khôn ngoan (aka memcmp và bạn bè) - có thể có vấn đề do căn chỉnh cấu trúc thành viên. I E. trình biên dịch đôi khi đặt "khoảng trống" trong bố cục struct của bạn, để mỗi thành viên sẽ có sự liên kết bắt buộc. Chúng không được khởi tạo và thường chứa rác.

Điều này có thể được giải quyết bằng cách không khởi tạo rõ ràng toàn bộ đối tượng của bạn. Nhưng, tôi không thấy bất kỳ lợi thế nào của memcmp so với tự động operator ==, đây là một so sánh thành viên khôn ngoan. Nó có lẽ có thể tiết kiệm một số kích thước mã (một cuộc gọi duy nhất để memcpy vs đọc rõ ràng và so sánh), tuy nhiên từ quan điểm hiệu suất này có vẻ là khá nhiều như nhau.

Answer 2

Mặc định == là nhanh cho các đối tượng nhỏ, thông minh hơn "thông minh hơn" mặc định. Như đã nói, tùy chọn 3 là sai, do thực tế là các trường thường được đệm để tôn trọng căn chỉnh dữ liệu và vì lý do tối ưu, các byte được thêm vào không được khởi tạo thành 0 (có thể điều này được thực hiện trong DEBUG). phiên bản).

tôi có thể đề nghị bạn để khám phá những tùy chọn để chia kiểm tra theo hai giai đoạn:

• giai đoạn đầu tiên, tạo ra một số loại nhỏ & thành viên nhanh đến nỗi "nén" tình trạng của instance (suy nghĩ như một băm); trường này có thể được cập nhật mỗi lần một số thay đổi trường lớn, ví dụ như các phần tử của mảng stl. Thay vì kiểm tra các trường được thay đổi thường xuyên và trạng thái "nén" này trước để so sánh thận trọng (ví dụ, tổng của tất cả int trong mảng hoặc có thể là xor)
• giai đoạn thứ hai, hãy sử dụng kiểm tra sâu cho từng thành viên . Đây là séc chậm nhất nhưng đầy đủ, nhưng có khả năng sẽ chỉ được kích hoạt đôi khi