2017-01-26 15 views
0

Кадр стека потоков создается при вызове метода, а создание фреймов стека отрицательно влияет на производительность Java-программы. Я хочу знать, насколько это эффект?Может ли реорганизация мая отрицательно повлиять на производительность Java?

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

Например:

Перед рефакторинга:

public class MyClassA { 
    public void doTask1(){ 
     // here is very verbose code 
    } 
} 

После переработан:

public class MyClassA { 
    public void doTask1(){ 
     taskPart1(); 
     taskPart2(); 
     taskPart3(); 
    } 
    public void taskPart1(){ 
     // do something that used to be in doTask1.. 
    } 
    public void taskPart2(){ 
     // do something that used to be in doTask1.. 
    } 
    public void taskPart3(){ 
     // do something that used to be in doTask1.. 
    } 
} 
+1

Если вы говорите о рефакторинге в целом, это означает: реструктурировать код по-другому (что бы это ни было), тогда этот вопрос не имеет значимого ответа. Это полностью зависит от того, как именно вы его реорганизуете. У вызовов методов есть некоторые накладные расходы, но «рефакторинг» не всегда означает, что будет больше вызовов методов. Кроме того, JVM строит простые методы, так что накладные расходы на вызов метода отсутствуют. – Jesper

+0

@SteveSmith О, спасибо, что уведомил меня об этом вопросе. Думаю, мне нужно удалить его. – ParkCheolu

+0

Это может даже улучшить * производительность, если есть разница вообще. Скорее всего, код рефакторинга используется в отдельных методах, потому что он используется не один раз, поэтому общий код имеет более высокий шанс получить оптимизацию, в интересах всех абонентов или б) исходный код слишком велик, поэтому реорганизованный код может пригодиться из того, что оптимизатор JVM лучше с меньшими методами. Но разница для одного метода, вероятно, скрыта в шуме других факторов. – Holger

ответ

2

Накладные вызов метода является далеко не достаточно, чтобы оправдать любые преждевременные оптимизации/заботы о качестве. Это определенно недостаточно значимо, чтобы вы не могли создавать и вызывать методы, где они имеют хорошее смысловое значение.

Плюс, компилятор может даже встроить их.

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

+0

Я скорее не согласен. Накладные расходы метода довольно велики для тривиальных методов (особенно геттеров). Но везде, где это важно, тривиальный метод встраивается, поэтому накладные расходы равны нулю. +++ Тем не менее, я согласен с вашим заключением. – maaartinus