Otimização de código.

Moderador Membro desde: 23/12/2006 21:05:04 Mensagens: 3083 Offline

Oi,

Um colega de trabalho, perguntou qual a diferenca e qual situação usar para comparar uma String.. se vazia ou se existir conteudo.

situação 1:

ou

situação 2:

Então, respondi a segunda opção, porém não souber explicar o motivo hehehe...
algum comentario a respeito?

Tchauzin!

Com a primeira opção vc estará criando uma String a mais na memória.
Já com a segunda é apenas uma comparação com um tipo primitivo.

equals() compara o conteudo da String e == compara a referencia.

De qualquer forma, tem o compareTo e compareToIgnoreCase.

This message was edited 3 times. Last update was at 25/04/2008 07:24:13

O length é mais rápido por se tratar apenas da leitura de um atributo e da comparação no seu if, observe (esses códigos foram retirados da classe String):

No caso do equals, nessa situação específica, você vai ter um processo lijeiramente mais longo, pois serão feitas três comparações. A primeira, testa se a string passada no parâmetro é a própria instância (o que nunca vai ocorrer). A segunda, testa se o objeto passado por parâmetro é realmente um String (o que sempre vai ser). E a terceira, finalmente, testa se o tamanho das Strings bate (o que só será verdade para um string vazio).

Usando o equals é ainda mais recomendado colocar a constante na frente, assim:

Isso dá uma vantagem adicional, pois o código também falha caso a string seja nula. Nos seus exemplos, você acabaria com um NullPointerException.

Agora, não creio que isso seja otimização de código, a menos que você esteja num loop realmente intenso, comparando milhares de Strings por segundo. Provavelmente haverá outros locais muito piores na sua aplicação. Não adianta "otimizar" pontos fora desses gargalos. Você só aumentará o tempo ocioso do sistema, que espera o gargalo passar. Sempre que se falar em otimização, rode um profiler, como o do Netbeans, e identifique os pontos de baixa performance. Otimize apenas esses pontos.

Otimização tem um custo: ela torna o código mais complexo e muito menos flexível. E deve ser uma preocupação apenas nos momentos de projeto e nos pontos críticos identificados no código.

Foxlol wrote:Com a primeira opção vc estará criando uma String a mais na memória.
Já com a segunda é apenas uma comparação com um tipo primitivo.

É muito provável que essa String venha do Pool de Strings. Não lembro onde li, mas creio que a String nula sempre esteja por lá.

This message was edited 1 time. Last update was at 25/04/2008 07:32:35

Respondendo, o == é mais rapido, tinha esquecido

Explicando o por que:

O Java suporta algo chamado de "interning". Quando o metodo intern() é invocado em uma String, é feito um lookup em uma tabela interna de Strings. Se uma String com o mesmo conteudo já está nesta tabela, a referencia para ela e retornada, do contrario, a String é adicionada a tabela e a referencia a ela é retornada.

No fim, este processo faz com que todas as Strings com o mesmo conteudo apontem para o mesmo objeto, salvando espaço e permitindo a comparação com ==, que é muito mais rapida do que o equals, como o vinny explicou.

Referencia: http://javatechniques.com/blog/string-equality-and-interning/

This message was edited 3 times. Last update was at 25/04/2008 07:43:16

aleck wrote:Respondendo, o == é mais rapido, tinha esquecido

Realmenta. Mas isso não serve para esse tipo de comparação que a Lina propôs.
Strings de conteúdo igual não são necessariamente iguais e dificilmente podemos afirmar que a String na variável veio de uma constante ou teve o seu intern() invocado.

Teste você mesmo:

Strings lidas de bancos de dados, ou capturadas de um JTextField não entram nesse caso.
É exatamente o alerta que o artigo dá no final.

Em todo caso, comparar com == envolve uma comparação de endereços de memória, que é um int. Enquanto com o length() envolve a comparação com um inteiro, que também é um int. A performance dos dois é provavelmente a mesma.

This message was edited 3 times. Last update was at 25/04/2008 08:04:48

E como vc garante que o conteudo é o mesmo com o length? Já que ele só compara o tamanho.

Provavelmente você terá que fazer uma comparação posterior, que somada deixara o processo mais lento.

Ah! Deixa pra la, acabei perdendo o foco do topico que era a comparação do equal com o lenght

ViniGodoy wrote:

aleck wrote:Respondendo, o == é mais rapido, tinha esquecido

Realmenta. Mas isso não serve para esse tipo de comparação que a Lina propôs.
Strings de conteúdo igual não são necessariamente iguais e dificilmente podemos afirmar que a String na variável veio de uma constante ou teve o seu intern() invocado.

Teste você mesmo:
String x = "Vinicius"; String y = new String("Vinicius"); if (x == y) System.out.println("É igual"); else System.out.println("É diferente");

Strings lidas de bancos de dados, ou capturadas de um JTextField não entram nesse caso.
É exatamente o alerta que o artigo dá no final.

Em todo caso, comparar com == envolve uma comparação de endereços de memória, que é um int. Enquanto com o length() envolve a comparação com um inteiro, que também é um int. A performance dos dois é provavelmente a mesma.

Bah.. que macabro, essas 2 Strings são diferentes mesmo...

Mas se for para testar se está vazia ou não, o lenght é melhor.

String s = "abc"; // creates one String object and one
// reference variable

In this simple case, "abc" will go in the pool and s will refer to it.

String s = new String("abc"); // creates two objects,
// and one reference variable

In this case, because we used the new keyword, Java will create a new String object in normal (non-pool) memory, and s will refer to it. In addition, the literal "abc" will be placed in the pool.

Retirado do livro da Kathy

aleck wrote:E como vc garante que o conteudo é o mesmo com o length? Já que ele só compara o tamanho.

Não garante. Mas o objetivo era testar se a String era vazia. Nesse caso, com certeza o length é 0.

Não adianta... se precisar comparar duas Strings, ou você terá que usar o equals da classe String, ou o equals da classe Collator (caso queira, por exemplo, desprezar os acentos).

Entusiasta Java Membro desde: 03/07/2006 12:32:49 Mensagens: 15 Offline

ViniGodoy wrote:

Foxlol wrote:Com a primeira opção vc estará criando uma String a mais na memória.
Já com a segunda é apenas uma comparação com um tipo primitivo.

É muito provável que essa String venha do Pool de Strings. Não lembro onde li, mas creio que a String nula sempre esteja por lá.

Isso, toda constante string fica na tabela de símbolos do interpretador. Será "desperdício" de memória se essa constante aparecer uma única vez na aplicação.

Flw

Moderador Membro desde: 23/12/2006 21:05:04 Mensagens: 3083 Offline

Oi,

vlw pelas respostas!

Tchauzin!

This message was edited 1 time. Last update was at 25/04/2008 17:31:20

daniel_s wrote:...
Isso, toda constante string fica na tabela de símbolos do interpretador. Será "desperdício" de memória se essa constante aparecer uma única vez na aplicação.
Flw

Daniel,

em tese o próprio paradigma orientado objeto tem esse efeito colateral (de desperdício de memória), mas em função da grande necessidade de ponteiros associativos...

Com relação ao cache interno de Constantes String do java e elembrando que um objeto String é "imutável", a equipe da SUN quando escrever essa parte da especificação estava em mente com a seguintes situação:

String a = "SACANA";
String b = "CANA";
String c = "ANA";

Neste caso seriam necessários os famosos ponteiros para os endereçõs de memória mais 16 bytes para a informação texto (lembrando que cada String tende a ter um terminador...). Com o Cache intern o java faz com que as mesmas String ocupem apenas 7 bytes. Economia de mais de 50% neste exemplo.
A Lógica vem de que a String é "imutável". O ponteiro de a, supomos inicia na posição 1000, o ponteiro de b inicia na posição 1002 e a de c na posição 1003.

E até onde eu me lembro, o cache é implementado segundo o conceito de LRU (http://en.wikipedia.org/wiki/Cache_algorithms).

fw

Entusiasta Java Membro desde: 03/07/2006 12:32:49 Mensagens: 15 Offline

No caso de variáveis sim, estava referenciando constantes. Essas são tratadas de forma diferente:

A constante "SACANA" é tratada como uma única instância String.

http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html

"(...) The Java programming language requires that identical string literals (that is, literals that contain the same sequence of characters) must refer to the same instance of class String (...)"

Abraços

Notícias, artigos e o maior fórum brasileiro sobre Java