Perda de performance por chamada de métodos

Programação Java
#1

Olá pessoal, alguém tem algum material indicando se java tem perda de performance se ouver muitas chamadas de métodos em um código? Eu queria saber se alguém ja pesquisou isso e/ou tem um material legal falando disso.

Abraços…

#2

Isso vai depender mais da complexidades e implementação dos métodos, do que as chamadas em si.

#3

eu nunca pesquisei sobre isso, mas posso expressar minha humilde opinião.

sinceramente eu acho que se existir uma perda de performance, esta será insignificante.

Portanto, não vá criar mais um daqueles métodos de 100 linhas só porque alguém te disse que chamar método você perde performance. Divida as responsabilidades…

Recomendo a leitura:

#4

Marcelo, postei no seu blog!

Primeiramente sigo muito essa ideia de uma funcao por metodo.
Eu melhoraria ainda mais esse codigo:
Segue abaixo:

public void inserir(Contato pContato) throws ExcecaoNegocio {
     if (!isContatoPreenchido(pContato)){
          throw new ExcecaoNegocio("Objeto inválido");
      }
     dao.inserir(pContato);
 }

// O nome nao ficou bem legal, mas estou sem muita ideia, Queria mesmo mostrar que com apenas 2 metodos da para fazer o mesmo e eu uso “is” sempre que um metodo retorna um boolean.

private boolean isContatoPreenchido(Contato pContato) {
   if (pContato.getNome().isEmpty()) || pContato.getTelefone().isEmpty()){
return false;
      }
     return true;
   }
#5

Se um método for suficientemente pequeno, o Java, ao compilar dinamicamente seu código, vai remover a chamada da função (“inline call”).
Não se acanhe de criar aqueles getters & setters - se eles não forem grandes, serão substituídos pelo acesso direto à variável (embora você não perceba isso no depurador de sua IDE preferida, já que nesse ambiente o Java volta de propósito para o modo interpretado para facilitar a depuração.)

#6

Eu costumo a evitar os ifs quando é só para retornar um valor booleano.

No meu caso, deixaria assim:

private boolean isContatoPreenchido(Contato pContato) { return !pContato.getNome().isEmpty() && !pContato.getTelefone().isEmpty(); }

Realmente, a chamada de método leva um tempo insignificante e no java tem ainda um problema adicional: é difícil ser medida.

A JVM é capaz de identificar e fazer o inline automático de diversos métodos, eliminando totalmente o overhead de uma chamada.

Mesmo em métodos virtuais, como é o caso de todos os métodos em java, a indireção vai transformar uma operação de 1 passo em uma de 3 passos, e aqui estamos falando de operações extremamente rápidas, ciclos de clock mesmo.

Em uma máquina como as de hoje em dia, essa não deve ser sua preocupação.

Quanto mais otimizado um programa é, mais abaixo na seguinte lista ele se encontra. As otimizações em redução de indireção e chamadas de método estão no último item da lista.

  1. Eficácia: Ou seja, em primeiríssimo lugar, devemos fazer um programa que funcione corretamente. As lógicas devem ser revisadas e o programa deve funcionar de acordo com os critérios estabelecidos;
  2. Eficiência: Procura-se substituir algoritmos menos otimizados por outros, otimizados. Aqui estamos falando de algoritmos testados, como trocar BubbleSort por QuickSort. Os pontos de gargalo são encontrados com o uso de um profiler, e métodos menos eficientes são corrigidos com técnicas bem conhecidas, como caches;
  3. Especialidade: Aqui busca-se algoritmos mais eficientes para tipos específos de dados e para o caso exclusivo de uma determinada regra de negócio ou cliente. Abre-se mão da flexibilidade, em prol da performance;
  4. Ilegibilidade: Reduz-se indireção de código (chamadas de métodos), organiza-se a ordem dos atributos para serem “cache friendly”, utiliza-se shift left ao invés de multiplicações por números de dois, e outras coisas punk do gênero. O código deixa de ser fácil de entender e de manter. Uma mera troca da ordem em que os atributos são declarados podem ter impacto na performance do sistema. Geralmente, esse passo só é atingido por linguagens que te permitam acesso de mais baixo nível ao sistema, e que não te encapsulem aspectos do hardware. O que certamente não é o caso do Java.

É importante ressaltar que quanto mais para baixo na lista, mais caro é o sistema e mais difícil ele é de manter. Via de regra, os sistemas comerciais devem se manter no item 2. Em alguns casos específicos, podem descer para o 3. Mas, a menos que você esteja produzindo firmware ou killer games, não vejo porque entrar no item 4. E ainda sim, se for esse seu caso, você deveria estar usando C++/C, não Java.

#7

Do jeito que o grande Vini falou, é melhor ainda!

#8