Исправление korvin_, (текущая версия) :
BigDecimal медленней на порядок, занимает под 32 байта на значение. А в System.Decimal четко 16 байт из 4 интов.
Так в Java заголовки объектов [url=https://www.baeldung.com/java-memory-layout]в принципе жирные[/url]:
For normal objects in Java, represented as instanceOop, the object header consists of mark and klass words plus possible alignment paddings. After the object header, there may be zero or more references to instance fields. So, that’s at least 16 bytes in 64-bit architectures because of 8 bytes of the mark, 4 bytes of klass, and another 4 bytes for padding.
А System.Decimal — структурка, value type без жирного заголовка, вот тебе и 16 байт разницы.
Напишешь ты свой класс с четырьмя интами? 16 байт на инты + 16 байт — заголовок. Те же 32 байта. И чего?
Для библиотечного BigDecimal хотя бы есть шанс наличия специальных оптимизаций в JVM.
Исходная версия korvin_, :
BigDecimal медленней на порядок, занимает под 32 байта на значение. А в System.Decimal четко 16 байт из 4 интов.
Так в Java заголовки объектов [url=https://www.baeldung.com/java-memory-layout]в принципе жирные[/url]:
For normal objects in Java, represented as instanceOop, the object header consists of mark and klass words plus possible alignment paddings. After the object header, there may be zero or more references to instance fields. So, that’s at least 16 bytes in 64-bit architectures because of 8 bytes of the mark, 4 bytes of klass, and another 4 bytes for padding.
А System.Decimal — структурка, value type без жирного заголовка, вот тебе и 16 байт разницы.
Напишешь ты свой класс с четырьмя интами? 16 байт на инты + 16 байт — заголовок. Те же 32 байта. И чего?
Для библиотечного BigDecimal хотя бы есть шанс наличия специальных оптимизаций в JIT-компиляторе.