рефакторинг массивов Java и примитивов (дважды [] []) к Наборам и Дженерикам (Список <Список <Дважды>>)

Общая рекомендация - отдавать предпочтение обобщенным коллекциям над массивами в Java, но это только рекомендация. Моей первой мыслью было бы НЕ менять этот рабочий код. Если вы действительно хотите внести это изменение, протестируйте оба подхода.

Как вы говорите, производительность имеет решающее значение, и в этом случае код, который соответствует требуемой производительности, лучше, чем код, который этого не делает.

Вы также можете сталкиваются с проблемами автоматической упаковки при упаковке / распаковке двойников - потенциально более тонкая проблема.

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

Я считаю, что массивы - лучший способ хранить данные процесса в алгоритмах. Поскольку Java не поддерживает перегрузку операторов (одна из причин, почему я думаю, что массивы в ближайшее время не устареют), переключение на коллекции затруднит чтение кода:

double[][] matrix = new double[10][10];
double t = matrix[0][0];

List<List<Double>> matrix = new ArrayList<List<Double>>(10);
Collections.fill(matrix, new ArrayList<Double>(10));
double t = matrix.get(0).get(0); // autoboxing => performance

Насколько я знаю, Java предварительно сохраняет некоторые объекты-оболочки для экземпляров Number (например, первых 100 целых чисел), чтобы вы могли получить к ним доступ быстрее, но я думаю, что это не очень поможет с таким количеством данных.

Когда вы знаете точные размеры списка, вам следует придерживаться массивов. Массивы по своей сути неплохие и никуда не денутся.

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

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

Для ясности, взаимодействие с остальной частью кода Я бы хотел его реорганизовать.

Вместо изменения структуры данных я бы сосредоточился на переименовании и, возможно, перемещении некоторой части кода в частные методы. Глядя на код, я понятия не имею, что происходит, и проблема, как мне кажется, заключается в более или менее коротких технических именах переменных и полей.

Просто пример: один двумерный массив просто назван «матрица». Но очевидно, что это матрица, поэтому называть ее «матрицей» излишне. Полезнее было бы переименовать ее, чтобы стало понятно, для чего на самом деле используется эта матрица, какие данные внутри.

Другой кандидат - ваша вторая линия. С помощью двух рефакторингов я бы переименовал jj во что-нибудь более значимое и переместил выражение в частный метод с «говорящим» именем.

Я думаю, что вы можете не только придерживаться массивов, но и значительно улучшить этот код. Например:

• Действительно, не вычисляйте границы цикла каждый раз, сохраните их вне
• Вы неоднократно ссылаетесь на матрицу [i]. Просто сохраните ссылку на этот подмассив вместо того, чтобы каждый раз разыменовывать 2D-массив
• Этот трюк становится еще более полезным, если вы можете перебирать i во внешнем цикле вместо внутреннего
• Это становится экстремальным, но сохраняет значение of j-1 в локальном может даже оказаться оправданным, а не пересчитывать
• Наконец, если вы действительно действительно беспокоитесь о производительности, запустите оптимизатор ProGuard над полученным байтовым кодом, чтобы он выполнил некоторые оптимизации компилятора, такие как развертка или оптимизация с помощью глазка

Я думал, что компиляторы должны были быть Умно, делая такую ​​вещь. Делать Нам нужно все еще сделать это?

Вы, вероятно, правильно, что JIT позаботится об этом, но если этот раздел настолько эффективнее, критично, пытаясь и бенчмаркинг не повредит.