Наследование против генерации кода для повышения производительности?

Question

Я пытаюсь получить максимальную производительность от фрагмента кода, который выглядит примерно так

interface DbStream {
    void writeInt(int x);
    void writeString(String s);
    // etc, somewhere around 20 different types
}

interface Writer {
    void write(DbStream stream, Object value);
}

Writer[] writers = new Writer[NUM_COLS];
DbStream stream;
Object[][] src = new Object[NUM_ROWS][NUM_COLS];

for (int row = 0; row < NUM_ROWS; row++) {
    for(int col = 0; col < NUM_COLS; col++) {
        writers[col].write(stream, src[row][col]);
    }
}

Каждая реализация интерфейса Writer выполняет необходимые преобразования и вызывает правильный метод DbStream. Код использует наследование, поэтому эти вызовы не встроены. Будет ли улучшение производительности, если внутренний l oop развернут вручную, чтобы он содержал 200-300 вызовов методов stati c? Программа будет использовать JDK 13, если это имеет значение.

Answer 1

Я пытаюсь добиться максимальной производительности от фрагмента кода ...

Обычно это неправильный подход. Лучшим подходом является оптимизация кода, который явно снижает производительность вашего приложения. Кроме того, «максимум» - не лучшая цель. Лучшая цель - «достаточно хороша». (До определенного момента время разработчика программного обеспечения дороже, чем время процессора. И это, безусловно, более дефицитный товар!)

Вот что я рекомендую вам сделать.

1. Завершите работу своего приложения.

2. Создайте реалистичный c тест, который проверяет этот код на реальных данных.

3. Профиль приложение, запускающее тест, чтобы измерить, какой процент времени ваше приложение проводит в этой части кода.

4. Оцените потенциальную производительность, которую вы можете получить за счет оптимизации. Например, если встраивание этих вызовов улучшает этот код на 10%, и этот код представляет 5% от общего времени ЦП приложения, то вы получите общее увеличение производительности ЦП на 0,5% от этой оптимизации.

5. Теперь решите:

   • Стоит ли возможное / вероятное повышение производительности усилий по разработке?
   • Стоит ли (гипотетически) снизить ремонтопригодность системы?

6. Если да: выполните оптимизацию и измерьте .

   • Вы действительно достигли ожидаемой производительности?
   • Стоит ли «ущерб» ремонтопригодности?

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

В этом случае, как мне кажется, предложенная вами оптимизация, вероятно, даст небольшую разницу в производительности. Включение вызовов вручную может сократить количество машинных инструкций (скажем, 3 или 4) на вызов. Однако я сомневаюсь, что это окажет существенное влияние на общую производительность приложения.

Answer 2

Спецификации JDK не дают никаких конкретных обещаний относительно производительности и не запрещают способ, которым эти две концепции должны функционировать, что является очевидной дырой в производительности. архитектура, ОС и фаза луны.

Используйте что-то вроде JMH , чтобы получить фактический результат, запускайте его как можно ближе к реальным обстоятельствам «реальной жизни», насколько вы можете ( запустите его на том же оборудовании под аналогичной нагрузкой и убедитесь, что код, который вы тестируете, настолько похож, насколько это возможно). это будет иметь значение, поскольку БД или, альтернативно, инфраструктура вокруг нее (например, создание TCP-пакетов для отправки их в БД, даже если она выполняется локально и реализуется в памяти) будет на несколько порядков медленнее чем все это. Я предполагаю, что ваш результат JMH будет очень близким (достаточно близким, чтобы любая разница, которую вы наблюдаете, является статистическим шумом).