Cách sử dụng BigDecimal sẽ ảnh hưởng đến hiệu suất của ứng dụng?

Question

Tôi muốn sử dụng BigDecimal để biểu thị các số chính xác tùy ý như giá cả và số tiền trong ứng dụng giao dịch có độ trễ thấp với hàng nghìn đơn đặt hàng và báo cáo thực hiện mỗi giây.

Tôi sẽ không thực hiện nhiều thao tác toán học, vì vậy câu hỏi không phải là về hiệu suất của BigDecimal, mà là khối lượng lớn các đối tượng BigDecimal sẽ ảnh hưởng đến hiệu năng của ứng dụng.

Mối quan tâm của tôi là số lượng lớn các đối tượng BigDecimal tồn tại ngắn sẽ gây căng thẳng cho GC và dẫn đến Dừng tạm dừng lớn hơn trong bộ thu CMS - và điều này chắc chắn là điều tôi muốn tránh.

Bạn có thể vui lòng xác nhận mối quan tâm của tôi và đề xuất các lựa chọn thay thế để sử dụng BigD không? Ngoài ra, nếu bạn nghĩ rằng mối quan tâm của tôi là sai - hãy giải thích lý do.

Cập nhật:

Cảm ơn tất cả những người đã trả lời. Bây giờ tôi tin rằng việc sử dụng BigDecimal sẽ làm giảm độ trễ của ứng dụng của tôi (mặc dù tôi vẫn có kế hoạch đo lường nó).

Hiện tại, chúng tôi quyết định gắn bó với giải pháp "rất không OOP" (nhưng không có độ chính xác) - sử dụng hai int s, một cho chú giải và một cho số mũ. Lý do đằng sau điều này là nguyên thủy được đặt trên ngăn xếp, không đống, và do đó không phải chịu thu gom rác thải.

Answer 1

Nếu bạn đang phát triển một chương trình giao dịch có độ trễ thấp và bạn thực sự muốn cạnh tranh về độ trễ, sau đó BigDecimalkhông phải dành cho bạn, nó là đơn giản như vậy. Trong trường hợp micro giây quan trọng, việc tạo đối tượng và bất kỳ phép toán thập phân nào cũng quá đắt.

tôi cho rằng cho gần mọi người khác, sử dụng BigDecimal là không có trí tuệ bởi vì nó sẽ có ít nhìn thấy ảnh hưởng đến hiệu suất ứng dụng.

Trong các hệ thống quan trọng có thời gian chờ đưa ra quyết định giao dịch, tạm ngưng thu gom rác không thể đoán trước là hoàn toàn ngoài câu hỏi, trong khi các thuật toán thu gom rác hiện tại tuyệt vời trong sử dụng bình thường, chúng không nhất thiết phải phù hợp khi một sự chậm trễ 5 mili giây có thể khiến bạn mất nhiều tiền. Tôi hy vọng rằng các hệ thống lớn được viết theo một phong cách rất không OOP, với ít hoặc không có đối tượng nào được sử dụng ngoài một số chuỗi nội bộ (đối với các mã và dạng tương tự).

Bạn chắc chắn sẽ cần phải sử dụng double (hoặc thậm chí float) và mất tính chính xác trúng.

Answer 2

Các JVM hiện khá tốt về mặt xử lý việc tạo và hủy các đối tượng tồn tại trong thời gian ngắn, do đó, đó không phải là điều lo lắng một lần.

Tôi khuyên bạn nên xây dựng mô hình về những gì bạn muốn làm và đo nó. Điều đó sẽ đáng giá hơn bất kỳ câu trả lời 'lý thuyết' nào mà bạn có thể nhận được :-)

Nhìn vào miền vấn đề cụ thể của bạn, hệ thống tương tự tôi đã làm việc trong quá khứ rất tốt bằng cách sử dụng dữ liệu đôi bạn muốn sử dụng BigDecimal cho, và có thể đáng xem xét lại suy nghĩ của bạn trong lĩnh vực này. Một cái nhìn lướt qua tại BigDecimal cho thấy nó có 5 hoặc 6 trường, và mức tiêu thụ bộ nhớ thêm trên một đôi có thể lớn hơn bất kỳ lợi ích chức năng nào bạn có.

Answer 3

BigDecimal có hiệu suất thấp hơn nhiều so với, ví dụ: long, double hoặc thậm chí Long. Cho dù điều đó sẽ tạo sự khác biệt đáng kể cho hiệu suất của ứng dụng của bạn phụ thuộc vào ứng dụng của bạn.

Tôi khuyên bạn nên tìm phần chậm nhất trong đơn đăng ký của mình và thực hiện kiểm tra so sánh về điều đó. Nó vẫn đủ nhanh sao? Nếu không, bạn có thể muốn viết một lớp không thay đổi nhỏ có chứa một đơn long, có thể kiểm tra tràn.

Answer 4

Tôi không chắc chắn các yêu cầu của bạn là gì, nhưng nói chung khi tính toán tài chính, người ta không thể trả tiền chính xác do các loại điểm động. Thông thường độ chính xác và làm tròn thích hợp là quan trọng hơn hiệu quả khi xử lý tiền.
Nếu bạn không phải đối phó với tỷ lệ phần trăm và tất cả số tiền là số nguyên, bạn có thể sử dụng các loại số nguyên (int, long hoặc thậm chí BigInteger) với một ý nghĩa 0,01 đơn vị tiền tệ của bạn.
Và ngay cả khi bạn nghĩ rằng bạn có thể đủ khả năng đạt được độ chính xác với loại double, có thể đáng thử trước với BigDecimal và kiểm tra xem nó có thực sự làm chậm cho bạn hay không.

Answer 5

Câu hỏi lớn đặt ra là: bạn có thực sự cần tính toán thập phân chính xác tùy ý không? Nếu các tính toán chỉ được thực hiện để phân tích dữ liệu và đưa ra quyết định dựa trên đó, thì làm tròn và tạo thành biểu diễn nhị phân giữa các bit ít quan trọng nhất có thể không liên quan đến bạn; chỉ cần tiếp tục và sử dụng double (và phân tích các thuật toán của bạn cho numerical stability).

Nếu bạn đang thực sự thực hiện giao dịch trong đó các con số phải thêm chính xác và các vấn đề chính xác thì double không phải là một tùy chọn. Có lẽ bạn có thể tách riêng hai phần này trong ứng dụng của mình và chỉ sử dụng BigDecimal trong phần giao dịch.

Nếu điều đó là không thể, thì bạn hoàn toàn không may mắn. Bạn cần một thư viện toán học BCD và tôi không nghĩ Java có một thư viện. Bạn có thể thử viết của riêng bạn, nhưng nó sẽ được rất nhiều công việc và kết quả có thể vẫn không được cạnh tranh.

Answer 6

Tôi làm việc cho một nhóm tiến hành đánh giá hiệu suất và tối ưu hóa trên các ứng dụng, đã có một ứng dụng gần đây đang sử dụng Java Big Decimal. Các vấn đề hiệu suất đáng kể đã được quan sát với việc sử dụng bộ nhớ. Sau đó chúng tôi chuyển sang Newton Raphson cho phép chúng tôi theo kịp tính chính xác với các phép tính và cho thấy hiệu suất tốt hơn đáng kể với số thập phân lớn.

Chỉ cần thêm .. khi chúng ta sử dụng đôi chúng ta đã thấy một sự mất mát lớn trong chính xác như mong đợi

Answer 7

tại sao bạn không sử dụng một thời gian dài với một số ngụ ý các trường hợp số thập phân? Ví dụ: giả sử bạn có 8 chữ số thập phân ngụ ý, sau đó 0,01 sẽ là 1000000.