Оголошення декількох масивів з 64 елементами в 1000 разів швидше, ніж оголошення масиву з 65 елементів

Нещодавно я помітив, що оголошення масиву, що містить 64 елементи, відбувається набагато швидше (> 1000 разів), ніж оголошення масиву того ж типу з 65 елементами.

Ось код, який я використовував для перевірки цього:

public class Tests{
    public static void main(String args[]){
        double start = System.nanoTime();
        int job = 100000000;//100 million
        for(int i = 0; i < job; i++){
            double[] test = new double[64];
        }
        double end = System.nanoTime();
        System.out.println("Total runtime = " + (end-start)/1000000 + " ms");
    }
}

Це працює приблизно за 6 мс, якщо я заміню new double[64]на new double[65]це, це займає приблизно 7 секунд. Ця проблема стає експоненціально більш серйозною, якщо робота поширюється на все більше і більше потоків, звідки і походить моя проблема.

Ця проблема також виникає з різними типами масивів, такими як int[65]або String[65]. Ця проблема не виникає з великими рядками:, String test = "many characters";але починає виникати, коли це змінюється наString test = i + "";

Мені було цікаво, чому це так, і чи можна обійти цю проблему.

Ви спостерігаєте поведінку, спричинену оптимізацією, виконаною компілятором JIT вашої Java VM. Ця поведінка відтворюється, що запускається зі скалярними масивами до 64 елементів, і не запускається з масивами більше 64.

Перш ніж вдаватися до деталей, давайте детальніше розглянемо тіло циклу:

double[] test = new double[64];

Тіло не має ефекту (спостережувана поведінка) . Це означає, що не має різниці поза виконанням програми, виконується цей оператор чи ні. Те саме стосується всього циклу. Тож може статися так, що оптимізатор коду переводить цикл до чогось (або нічого) з однаковою функціональною та різною поведінкою синхронізації.

Щодо орієнтирів, вам слід принаймні дотримуватися наступних двох рекомендацій. Якби ви зробили це, різниця була б значно меншою.

• Розігрійте компілятор JIT (і оптимізатор), виконавши еталон кілька разів.
• Використовуйте результат кожного виразу та друкуйте його в кінці еталону.

Тепер давайте вдамося в подробиці. Не дивно, що існує оптимізація, яка запускається для скалярних масивів, розмір яких не перевищує 64 елементів. Оптимізація є частиною аналізу Escape . Він поміщає маленькі предмети та малі масиви в стек, замість того, щоб розподіляти їх по купі - або навіть краще оптимізувати їх повністю. Деякі відомості про це можна знайти в наступній статті Брайана Гетца, написаній у 2005 році:

• Легенди про міські показники, переглянуті: розподіл відбувається швидше, ніж ви думаєте, і стає швидшим

Оптимізацію можна вимкнути за допомогою опції командного рядка -XX:-DoEscapeAnalysis. Магічне значення 64 для скалярних масивів також можна змінити в командному рядку. Якщо виконати програму наступним чином, різниці між масивами з 64 та 65 елементами не буде:

java -XX:EliminateAllocationArraySizeLimit=65 Tests

Сказавши це, я настійно не рекомендую використовувати такі параметри командного рядка. Сумніваюся, що це робить величезну різницю в реалістичному застосуванні. Я б використовував його лише тоді, коли б був абсолютно впевнений у необхідності - а не на основі результатів деяких псевдо-еталонів.

Існує будь-яка кількість способів, за якими може бути різниця, залежно від розміру об’єкта.

Як зазначив nosid, JITC може (найімовірніше) виділяти невеликі "локальні" об'єкти в стеку, а граничний розмір для "малих" масивів може становити 64 елементи.

Розподіл по стеку значно швидший, ніж розподіл по купі, і, більш конкретно, стеку не потрібно збирати сміття, тому накладні витрати на GC значно зменшуються. (І для цього тестового випадку накладні витрати на GC, ймовірно, становлять 80-90% від загального часу виконання.)

Крім того, після того, як значення виділено стеком, JITC може виконати "усунення мертвого коду", визначити, що результат newніколи ніде не використовується, і, переконавшись, що побічних ефектів не буде втрачено, виключити всю newоперацію, а потім сам (тепер порожній) цикл.

Навіть якщо JITC не робить розподілу стеків, цілком можливо, що об'єкти розміром менше певного розміру виділяються в купі інакше (наприклад, з іншого "простору"), ніж більші об'єкти. (Зазвичай, це не призведе до настільки значних різниць у термінах.)