Эффективный BigInteger в Java

Question

У нас есть набор мест в нашем продукте, где требуется BigInteger, так как числа могут быть довольно длинными. Тем не менее, в более чем 90% случаев они на самом деле не такие длинные и их легко можно удерживать в течение длительного времени.

Глядя на реализацию BigInteger, было бы довольно бесполезно использовать BigInteger там, где достаточно Long.

Имеет ли смысл создавать интерфейс, который имеет такие функции, как BigInteger (деление, умножение и т. Д.), И который будет реализован дочерним классом BigInteger и классом, обертывающим Long? Что-то вроде:

Interface: EfficientBigInteger
Class 1: MyBigInteger extends BigInteger imlpements EfficientBigInteger
Class 2: MyLong implements EfficientBigInteger (this will contain a Long, as we cannot extend the Long class)

Может быть, мы здесь не в том направлении?

Спасибо, Йон

ОБНОВЛЕНИЕ: Эти объекты (Long или BigInteger) хранятся в памяти довольно долгое время, поскольку они помогают нам идентифицировать проблемное поведение систем, с которыми мы взаимодействуем. Таким образом, объем памяти может быть проблемой. Это проблема, которую мы пытаемся избежать. Класс BigInteger имеет несколько полей (signum, mag array, bitcount и т. Д. И т. Д.), Которые вместе примерно вдвое больше, чем у класса, который инкапсулирует Long (принимая во внимание затраты памяти на наличие объекта в первую очередь). Это означает удвоение площади для того, что мы часто используем.

Answer 1

Нужно ли делать арифметику с этими значениями? Потому что, если вы это сделаете, то тот, который начинается с длинного, может стать BigInteger, и это звучит как боль: вам придется предшествовать каждой арифметической операции с тестом, который может пройти над MAX_LONG. Ну, я полагаю, вы могли бы заключить все это в свой класс-обертку. Сколько времени потребуется для проверки на переполнение, по сравнению со временем, которое класс BigInteger занимает для обхода массива из 1 или 2 элементов?

Если вы не занимаетесь арифметикой, экономия за счет использования длинной будет минимальной. Что вы делаете с BigInteger, просто читаете и пишете? В этом случае почти наверняка не стоит хлопот.

Лично, это то, что я хотел бы сделать сам, я понимаю ваше мышление. Но тогда я отступлю и скажу: действительно ли здесь проблема в производительности? Просто, сколько арифметики мы делаем? Какой прирост производительности мы получим? Стоит ли увеличивать сложность программы и, возможно, вносить ошибки?

Если у вас нет оснований полагать, что производительность действительно является проблемой и что это может иметь существенное значение, я бы не стал.

Answer 2

Я реализовал именно такую ​​вещь для компилятора Cobol примерно в 1986 году. Это не имело никакого значения для производительности: накладные расходы, связанные с определением, подходит ли он long, и затем преобразование его в long и затем обратно равнялись временисохранение.