Может ли наследование влиять на производительность приложения?

Question

Интересно, можно ли улучшить производительность приложения, используя как можно больше суперклассов?Мой вопрос о Kotlin, но я предполагаю, что ответ будет таким же для Java.

---

Допустим, у вас есть эта схема наследования (правый класс является подклассом класса слева от него):
A

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

Мой вопрос довольно прост: Если вы измените свой код, чтобы использовать только класс A вместо класса Z, будет ли код более производительным?

Заранее спасибоза ваши ответы.

Answer 1

Ответ - да.Например, если вы вызываете метод z.someMethod ().Hotspot сначала найдет метод в Z-классе.Если HotSpot не найдет целевой метод, он будет искать метод в родительском Z-образце.И продолжайте эти шаги, пока не найдете целевой метод.Поэтому поиск метода займет больше времени, если цепочка наследования длинная.

Однако HotSpot использует некоторый кэш для ускорения процесса.

HotSpot VirtualCalls

Answer 2

Если

"изменить код, чтобы использовать только класс A вместо класса Z"

включает конструкцию, тогда есть тривиальный ответ:

Создание и хранение объекта с меньшим количеством атрибутов / полей дешевле, чем создание объекта с большим количеством атрибутов, как с точки зрения памяти, так и с точки зрения времени, которое требуется для инициализации.

Кроме этого, я не ожидал бы существенного влияния на производительность.

---

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