Как использование BigDecimal повлияет на производительность приложения?

Если вы разрабатываете торговую программу с малой задержкой и действительно хотите конкурировать с точки зрения задержки, то BigDecimal не для вас, это так просто. Там, где важны микросекунды, создание объектов и любая десятичная математика слишком дороги.

Я бы сказал, что для почти всех остальных использование BigDecimal не составляет труда, потому что это будет иметь мало видимого влияния на производительность приложения.

В критически важных системах, принимающих торговые решения, любые непредсказуемые паузы для сборки мусора совершенно исключены, поэтому, хотя текущие алгоритмы сборки мусора фантастически хороши при обычном использовании, они не обязательно подходят. когда задержка в 5 миллисекунд может стоить вам больших денег. Я ожидаю, что большие системы были написаны в стиле, отличном от ООП, с небольшим количеством объектов или без них, кроме некоторых интернированных строк (для кодов и т.п.).

Вам обязательно нужно будет использовать double (или даже float) и принять точный удар.

В настоящее время JVM довольно хороши с точки зрения обработки создания и уничтожения недолговечных объектов, так что это не проблема, которая была раньше.

Я бы рекомендовал создать макет того, что вы хотите сделать, и измерить его. Это будет стоить намного больше, чем любые «теоретические» ответы, которые вы можете получить :-)

Глядя на вашу конкретную проблемную область, аналогичные системы, над которыми я работал в прошлом, очень хорошо работают, используя удвоения для данных, для которых вы хотите использовать BigDecimal, и, возможно, стоит пересмотреть свое мышление в этой области. Беглый взгляд на BigDecimal показывает, что у него 5 или 6 полей, а дополнительное потребление памяти по сравнению с одним двойным значением может перевесить любые преимущества функциональности, которые у вас есть.

BigDecimal имеет производительность намного ниже, чем, скажем, long, double или даже Long. Будет ли это иметь существенное значение для производительности вашего приложения, зависит от вашего приложения.

Я предлагаю найти самую медленную часть вашего приложения и провести сравнительный тест. Это все еще достаточно быстро? Если нет, вы можете написать небольшой неизменяемый класс, содержащий один long, возможно, проверяющий на переполнения.

Большой вопрос: действительно ли вам нужны десятичные вычисления произвольной точности? Если вычисления выполняются только для анализа данных и принятия решений на их основе, то артефакты округления и двоичного представления среди младших битов, вероятно, не имеют для вас значения; просто используйте double (и проанализируйте свои алгоритмы на предмет числовой стабильности).

Если вы на самом деле выполняете транзакции, в которых числа должны складываться, а точность имеет абсолютное значение, то double не вариант. Возможно, вы можете разделить эти две части своего приложения и использовать BigDecimal только в части транзакции.

Если это невозможно, то вам в значительной степени не повезло. Вам понадобится математическая библиотека BCD, и я не думаю, что в Java она есть. . Можно попробовать написать свой, но это будет много работы и результат все равно может быть не конкурентоспособным.

почему бы вам не использовать long с подразумеваемым числом десятичных регистров? Например, предположим, что у вас подразумевается 8 знаков после запятой, тогда 0,01 будет 1000000.

Я не уверен, каковы ваши требования, но обычно при выполнении финансовых расчетов нельзя допустить снижения точности, вызванного типами с плавающей запятой. Обычно точность и правильное округление важнее, чем эффективность при работе с деньгами.
Если вам не нужно иметь дело с процентами и все суммы являются целыми числами, вы можете использовать целые типы (int, long или даже BigInteger) с один означает 0,01 вашей денежной единицы.
И даже если вы думаете, что можете позволить себе точность с типом double, возможно, стоит сначала попробовать с BigDecimal и проверить, действительно ли он для вас медленный.

Я работаю в команде, которая занимается оценкой производительности и оптимизацией приложений. Недавно у меня было одно приложение, использующее Java Big Decimal. Наблюдались значительные проблемы с производительностью при использовании памяти. Позже мы перешли на Newton Raphson, что позволило нам сохранить точность вычислений и показало значительно лучшую производительность при работе с большими десятичными числами.

Просто добавлю... когда мы использовали удвоения, мы увидели огромную потерю точности, как и ожидалось.