Performance это праздник

[nehaev]

Ко всему этому еще стоит добавить, что оптимизировать глядя только на код — это вообще малоперспективное занятие. По уму вам надо сначала взять профайлер, найти узкие места и оптимизировать только их. Более того, необходимо с помощью соответсвующих тулов убеждаться, что каждая внесенная оптимизация дает измеримый прирост производительности.

[vladimir_dolzhenko]

Об использовании любого типа профилировщика — даже из желудей и палок и про то, что стоит, а что не стоит оптимизировать, говорит Алексей в докладе.

Это шаг №0 и я его неявно подразумеваю.

[m08pvv]

Это шаг №0 и я его неявно подразумеваю.

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

[sergey-b]

Поддержу. Как-то раз, чтобы заново подобрать оптимальные настройки -XX, удалил их все разом. Производительность увеличилась сразу на 40%. После этого я решил их не трогать, так как даже если я их сейчас подберу так, что разгоню систему процентов на 5, то в будущем все равно может оказаться, что эти настройки замедляют систему.

[23derevo]

люто, бешено плюсую.

[moonster]

Сколько раз на технических интервью на меня косо смотрели, когда говорил, что всякие -XX нужно трогать только от безысходности, если других способов улучшить производительность нет совсем. Теперь есть пруф, что так и надо. )

[vladimir_dolzhenko]

-XX:+MakeMeAlwaysHappy


[tagir_valeev]

System.arraycopy — довольно сложная штука и по одному тесту я бы вывод не делал. Например, если массивы разных типов (копируем из Object[] в String[]), то она вставит проверку типа каждого элемента, ни о какой векторизации речи не идёт. Зато, например, при копировании из String[] в CharSequence[] проверка типов пропадёт. Кроме того, если вы копируете какой-то диапазон элементов и статически не определяется, что выход за границы не происходит, для arraycopy совершенно точно проверка границ будет снаружи цикла. А вот удастся ли JIT-компилятору вынести её наружу из ручного цикла — я не уверен на 100%. В общем, я бы не стал всегда полагаться, что ручное копирование будет так же эффективно.

Вообще сам код интринсика в C2 вот он. Там 200 строк основного метода и это только верхушка айсберга, он вызывает ещё кучу вспомогательных. Можете посмотреть, сколько там разных веток и случаев.

[vladimir_dolzhenko]

И ещё есть узкоспециализированные реализации для примитивов — если я правильно понял, то arrayCopy для long[] вырождается в такую простыню (для x86) — и вот их оптимизировать это скорее гадание на кофейной гуще — что лучше сработает векторизация, или intrinsic.

[SelecTee]

Optimize empty HashMap and ArrayList коммит в openjdk

и тут же откатили

открыл щас JDK 1.8.0.121

    /**
     * Shared empty array instance used for default sized empty instances. We
     * distinguish this from EMPTY_ELEMENTDATA to know how much to inflate when
     * first element is added.
     */
    private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {};

    /**
     * Constructs an empty list with an initial capacity of ten.
     */
    public ArrayList() {
        this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA;
    }

[vladimir_dolzhenko]

это уже не тут же, но это ещё лишний раз показывает то, что оптимизации от одной minor-версии до другой minor-версии могут как протухать, так и жить и эволюционировать

[vladimir_dolzhenko]

и потом — через 10 дней накатили снова

[tagir_valeev]

А вот и устаревшие внутри-JDK-шные советы по оптимизации правят:

-        // (3)getClass().getClassLoader0() is expensive
-        // (4)There might be a timing gap in isTrusted setting. getClassLoader0()
+        // (3)There might be a timing gap in isTrusted setting. getClassLoader0()