Стратегии оптимизации вокруг вызовов интерфейса в Java

Question

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

В настоящее время я изучаю способы оптимизации приложения с помощью интерфейсных вызовов.

Я могу ограничить сложность моего заявления следующим:

1. Мне нужно только один раз динамически загрузить реализацию при запуске
2. Мне нужна только одна реализация провайдера для определенного набора интерфейсов для экземпляра приложения в любое время.

Буду признателен за любые стратегии, которые люди применяют на практике:

1. Сокращение вызовов интерфейса
2. Любые хитрости для общего вызова классов реализации интерфейса напрямую.
3. Различные способы получить больше преимуществ от любых оптимизаций компилятора.

Спасибо!

Answer 1

Некоторые заблуждения, на которые стоит обратить внимание.

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

2. Вы можете привести ссылку на интерфейс к конкретной ссылке и использовать ее вместо этого.Как правило, это плохая практика программирования и мало влияет на производительность.Как правило, вы делаете это только тогда, когда правильный рефакторинг - это больше работы, чем стоит.(Это не очень хороший подход к дизайну, но он может быть прагматичным)

3. Компилятор не оптимизирует код каким-либо существенным образом .Те несколько оптимизаций, которые он выполняет (например, встроенные константы времени компиляции), без которых вы, вероятно, могли бы обойтись.JVM выполняет полезные оптимизации во время выполнения.Второе предположение о том, что будет делать JVM и попытка оптимизировать ваш код, - это процесс с ошибками.Если вы попробуете 10 вещей, которые, по вашему мнению, должны помочь, 1 сделает это значительно быстрее, 6 не даст особой разницы, а 3 сделает медленнее.т. е. простой код имеет тенденцию оптимизироваться лучше всего.

В отличие от C ++, большинство JVM могут оптимизировать стоимость виртуальных функций, особенно если фактически используется только одна или две реализации.то есть он может оптимизировать код, основываясь на том, как он используется, а не на том, что компилятор может определять статически.

Answer 2

По звуку вы делаете это неправильно.

1. Хорошо продуманные интерфейсы уменьшают, а не увеличивают сложность приложения. Интерфейсы, обычно используемые с провайдером, должны помочь разделить систему на части. Если вы чувствуете, что было бы проще получить прямой доступ к реализации, то возможно, что ваши интерфейсы должны быть переработаны.

2. Затраты времени выполнения "интерфейсного вызова" настолько незначительны, что вы вряд ли когда-либо окажетесь в ситуации, когда это делает разницу между работающей и неработающей системой.

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

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