Fazer sobrecarga de métodos é menos performático? – java orientação-a-objetos desempenho

Estava lendo sobre interfaces como parte dos meus estudos e me deparei com uma classe com sobrecarga (overloading) de métodos, com dois comentários dizendo que aquilo deveria ser evitado. Fiquei em dúvida sobre isso afetar a performance. Afeta?

Não afeta a performance, pois o método que será invocado pode ser determinado em tempo de compilação.

Talvez o autor do comentário estivesse se referindo a evitar abusar de overloading, porque pode piorar a legibilidade.

Não. O desempenho deve ser o mesmo. O método a ser chamado é decidido no momento da compilação, baseado nos tipos dos argumentos, já que esses já são conhecidos nesse momento. Você pode imaginar que cada método com mesmo nome é traduzido pra um método com um nome único no bytecode, e cada chamada a eles é substituída pela chamada ao método correspondente. Dá pra ver assim que não precisa parar a chamada para verificar tabelas ou algo assim.

Note que isso é diferente de sobreposição (overriding). Nesse caso, é preciso decidir em tempo de execução qual método deve ser chamado (o mais específico possível, no caso). Isso é feito olhando tabelas de chamadas virtuais, o que acrescenta um custo.

De qualquer modo, como sempre que se fala em desempenho, o melhor a se fazer é preocupar-se antes em escrever o código mais claro e limpo possível, evitando otimizações prematuras. Se depois de pronto o desempenho estiver deixando a desejar, você deve fazer medidas para identificar onde está o “gargalo” da sua aplicação. Geralmente não está nesse tipo de detalhe.

A sobrecarga em si não afeta a performance porque são métodos como quaisquer outros, eles não possuem nada de especial a não ser o fato de existir o mesmo nome, mas tudo isto é decidido em tempo de compilação não gerando custo de execução.

Pode aumentar ligeiramente o tempo de compilação, mas irrisório.

O que pode ocorrer é que é normal em casos assim um método sobrecarregado chamar outro da sobrecarga passando algum argumento extra ou fazendo uma preparação antes ou tratando o resultado depois. Neste caso pode haver um pequeno overhead da chamada de um novo método. Mas também pode não ter porque o compilador e o JITter são espertos o suficiente para otimizar isto, se valer a pena e for possível.

De qualquer forma a alternativa seria a duplicação de código que é péssimo para a manutenção, eventualmente violando o DRY.

Não tenha medo de usar a sobrecarga onde fizer sentido. Só não use se os métodos fazem coisas diferentes. A sobrecarga deve ser usada quando a mesma ação será realizada com dados de entrada diferentes.

Pode ser que o comentário se referia a outra coisa. Se tivesse acesso ao código para ver contexto daria para responder melhor.

Sobre performance em chamadas de métodos em Java, primeiramente eu diria para não se preocupar tão fortemente com o assunto, para deixar para se preocupar quando a performance for um gargalo real. Em segundo lugar, eu diria que seu algoritmo está errado. Mas também não custa nada conhecer um pouco o funcionamento da JVM, certo?

Quando você compila um código Java, ele gera bytecodes da JVM. Quando há uma chamado de método/função, o compilador coloca um bytecode de invocação de método. Eu me lembro rapidamente das seguintes invocações:

• invokeStatic: para métodos estáticos; o binding é feito a nível de compilação, não precisando fazer uma busca muito grande;
• invokeSpecial: para construtores e métodos privados; também decidido na compilação;
• invokeVirtual: para chamadas de métodos de classe, usado para se fazer o polimorfismo; só é possível fazer o binding a nível de execução, então a JVM faz uma busca na tabela de métodos da classe, o que implica um pouco mais de de tempo;
• invokeInterface: para chamadas de métodos a partir de uma interface; semelhante ao invokeVirtual, só é possível determinar a nível de execução.

Exemplos de quando ocorrem as invocações

public interface Suricate {
  int seboso();
}

public class Marmota implements Suricate {
  @Override
  public int seboso() {
    return 1;
  }

  @Override
  public String toString() {
    return "marmota";
  }

  public Marmota() {
    System.out.println(seboso() + prvt() + sttc());
  }

   private int prvt() {
     return 4;
  }

  static int sttc() {
    return 5;
  }

  public int somaSeboso(Suricate s) {
    return seboso() + s.seboso();
  }
}

Ao se chamar new Marmota(), há um invokeSpecial chamando o construtor.

Dentro do construtor, há a chamada para 3 métodos de dentro da classe: “

• seboso(), chamado com invokeVirtual
• prvt(), chamado com invokeSpecial
• sttc(), chamado com invokeStatic

Ao se chamar somaSeboso, há duas chamadas de métodos:

• seboso(), que é a mesma coisa de this.seboso(), chamado com invokeVirtual
• s.seboso(), que é chamado através do invokeInterface

A velocidade de invocação em termos de velocidade é (mais velozes primeiros):

• invokeStatic
• invokeSpecial
• invokeVirtual
• invokeInterface

Eu não lembro se tem alguma relação entre invokeStatic e invokeSpecial

Eu também não sei como o invokeDynamics do Java 7 se encaixa nessa relação

O JITter também pode afetar positivamente a performance

Isso é só uma lembrança geral do esperado da execução da invocação de métodos, não tente forçar um método que naturalmente deveria ser chamado via invokeVirtual para ser chamado como invokeSpecial. Não é muito positivo você forçar níveis de abstração distintos daqueles que são naturais ao seu programa.