Профилирование Java: получатель частной собственности имеет большое базовое время

Это звучит очень своеобразно. Вы не вызываете переопределяющий метод по ошибке, не так ли?

У меня возникло бы желание загрузить демонстрационную версию YourKit. Это тривиально настроить, и это должно дать представление о том, что происходит на самом деле. Если и TPTP, и YourKit согласны, то происходит что-то странное (и я знаю, что это не очень помогает!)

Если возможно, попробуйте использовать другой профилировщик (хорошо работает Netbeans). Это может быть сложно сделать в зависимости от того, как настроен ваш код.

Возможно, что, как и многие другие инструменты, другой профилировщик даст другую информацию.

Действительно ли возврат локального примитива занимает больше времени, чем возврат вычисленного значения?

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

Но у вас нет локального значения (локальное значение в методе, а не в классе).

Что именно вы подразумеваете под «местным»?

Должен ли я смотреть на метрику, отличную от базового времени?

Я не использовал инструменты Eclipse, поэтому я не уверен, как они работают... может иметь значение, является ли это профилировщиком трассировки или выборки (два могут давать разные результаты для подобных вещей).

Вводят ли эти результаты в заблуждение, и мне нужно рассмотреть какой-либо другой инструмент профилирования?

Я бы рассмотрел другой инструмент, просто чтобы посмотреть, будет ли результат таким же.

Изменить на основе комментариев:

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

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

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

Профилировщики выборки быстрее, но менее точны (они просто угадывают, как часто выполняется строка кода).

Итак, если Eclipse использует профилировщик выборки, вы можете увидеть то, что вы считаете странным поведением. Переход на профилировщик трассировки покажет более точные результаты.

Если Eclipse использует профилировщик трассировки, то изменение профайлеров должно показать тот же результат (однако новый профилировщик может сделать более очевидным для вас, что происходит).

Звучит слегка обманчиво — возможно, профайлер убирает какие-то оптимизации?

Ради интереса попробуйте сделать метод final, что облегчит его встраивание. Это вполне может быть различием между свойством и FasterMethod. При реальном использовании HotSpot будет встраивать даже виртуальные методы до тех пор, пока они не будут переопределены в первый раз (IIRC).

РЕДАКТИРОВАТЬ: Отвечая на комментарий Брайана: Да, обычно это тот случай, когда создание чего-то окончательного не улучшит производительность (хотя это может быть хорошо с точки зрения дизайна :), потому что Hotspot обычно решает, будет ли он может быть встроен или нет в зависимости от того, переопределен он или нет. Я предположил, что этот профилировщик, возможно, испортил это.

РЕДАКТИРОВАТЬ: теперь мне удалось воспроизвести способ, которым HotSpot «отменяет» оптимизацию классов, которые еще не были расширены (или методы, которые не были переопределены). Это было сложнее сделать для серверной ВМ, чем для клиентской, но я это сделал :)

public class Test
{
    public static void main(String[] args)
        throws Exception
    {
        final long iterations = 1000000000L;
        Base b = new Base();
        // Warm up Hotspot
        time(b, 1000);

        // Before we load Derived
        time(b, iterations);

        // Load Derived and use it quickly
        // (Just loading is enough to make the client VM
        // undo its optimizations; the server VM needs more effort)
        Base d = (Base) Class.forName("Derived").newInstance();
        time(d, 1);

        // Time it again with Base
        time(b, iterations);
    }

    private static void time(Base b, long iterations)
    {
        long total = 0;
        long start = System.currentTimeMillis();
        for (long i = 0; i < iterations; i++)
        {
            total += b.getValue();
        }
        long end = System.currentTimeMillis();
        System.out.println("Time: " + (end-start));
        System.out.println("Total: " + total);
    }
}

class Base
{
    public int getValue() { return 1; }
}

class Derived extends Base
{
    @Override
    public int getValue() { return 2; }
}

Что-то, что имело большое значение для производительности такого рода методов (хотя это может быть в некоторой степени историческим), заключается в том, что размер вызывающего метода может быть проблемой. HotSpot (и серьезные конкуренты) с радостью встраивают небольшие методы (некоторые могут задохнуться от synchronized/try-finally). Однако если вызывающий метод большой, то может и не быть. Особенно это было проблемой со старыми версиями HotSpot C1/client, которые имели очень плохой алгоритм распределения регистров (теперь он имеет довольно хороший и быстрый алгоритм).