Otimização de código.

renrutal wrote:

Paulo Silveira wrote:Mesmo assim, ainda nao deve ser usado para concatenar dentro de um laco se a string que voce esta mexendo esta referenciada fora do laco! Ele geraria milhares de StringBuilders, estressando o GC. Fica uma carroca

Aí não tem versão de Java que resolva né? É problema de estrutura de código, não da linguagem.

Perfeito, isso mesmo.

Peraee!!!

Dexa eu ver se eu entendi ou to boiando.

Quer dizer que depois do Java 6, ao usar "+" para concatenar String, o compilador substitui automaticamente para StringBuilder?

O.o

Foxlol wrote:Peraee!!!

Dexa eu ver se eu entendi ou to boiando.

Quer dizer que depois do Java 6, ao usar "+" para concatenar String, o compilador substitui automaticamente para StringBuilder?

O.o

Desde o Java 1.0 é usando o StringBuffer.

O problema é que a primeira vez ele da new em String Buffer. Se estiver dentro de um loop, ja viu... Qual eh a solucao? Dar new FORA do laco, e dentro so chamar append. Mas isso ai o compilador nao faz.

Paulo Silveira wrote:

Foxlol wrote:Peraee!!!

Dexa eu ver se eu entendi ou to boiando.

Quer dizer que depois do Java 6, ao usar "+" para concatenar String, o compilador substitui automaticamente para StringBuilder?

O.o

Desde o Java 1.0 é usando o StringBuffer.

O problema é que a primeira vez ele da new em String Buffer. Se estiver dentro de um loop, ja viu... Qual eh a solucao? Dar new FORA do laco, e dentro so chamar append. Mas isso ai o compilador nao faz.

Eita, não sabia dessa!

Então dá pra concatenar Strings com "+" sem problemas, desde que não esteja em um loop. Ai tem que tomar este cuidade que vc falou.

Vlw

This message was edited 2 times. Last update was at 30/04/2008 09:16:40

sergiotaborda wrote:

ViniGodoy wrote:
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).

Não. "abc" e "def" têm o mesmo length. Só se o tamanho é igual é que se tem que passar a uma analise caracter a caracter. Os outros testes são otimizações. O segundo teste tb teste o null. Nem sempre vai ser uma string

Sérgio, estou falando do teste:

Que foi proposto pela Lina, no início do tópico. Não tem absolutamente nada a ver com coleções.

E, como mostrado no código fonte da classe String (está no início do tópico), são feitas 3 comparações, sendo 2 delas desnecessárias.

A primeira, verifica se o objeto recebido no parâmetro e o this são exatamente o mesmo objeto. No caso desse exemplo, as chances disso ocorrer são ridiculamente pequenas.

O segundo teste, verifica se o objeto recebido é realmente uma String. Da forma como a Lina usa isso sempre vai ser verdade. "" nunca será nulo e sempre será uma String. Não estou criticando o mérito desse teste, no caso de um método equals de verdade, ele é necessário. Mas o que ela quer não é testar igualdade, mas se um determinado String está vazio ou não.

Só então, é feito um cast, uma atribuição a uma variável "n" e uma comparação em para só então ocorrer a comparação com o tamanho, que você falou. Por favor, leia o tópico com mais atenção da próxima vez. Aliás, em momento algum falei sobre ser mais lento por haver comparação caracter a caracter.

A forma que eu recomendei foi o simples de tamanho == 0. Essa forma é, sim, mais rápida, já que poupa os dois testes iniciais que só são necessários e servem de otimização no caso do equals.

Mas, como eu ressaltei e volto a ressaltar, não adianta otimizar código se você não estiver num ponto que constitui um gargalo em sua aplicação.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

package testes;

public class TesteStrings {

private static final long ITERACOES = 100*1000*1000;
    private static final String TESTE_VAZIO = "";
    private static final String TESTE_NAO_VAZIO = "        ";
        
    public static void main (String[] args)
    {
        teste(TESTE_VAZIO, 10, ITERACOES);
        teste(TESTE_NAO_VAZIO, 10, ITERACOES);
    }
    
    private static void teste(String s, int loops, long iter)
    {
        long r1, r2, r3, r4;

r1 = r2 = r3 = r4 = 0;
        
        for (int n = 0; n < loops; n++)
        {
            r1 += testeLength(s, iter);
            r2 += testeEquals1(s, iter);
            r3 += testeEquals2(s, iter);
            r4 += testeIsEmpty(s, iter);
            
        }
        
        System.out.println("String \"" + s + "\"");
        System.out.println("Média em " + loops + " loops:");
        System.out.println("s.length()   " + r1/loops);
        System.out.println("s.equals(\"\") " + r2/loops);
        System.out.println("\"\".equals(s) " + r3/loops);
        System.out.println("s.isEmpty()  " + r4/loops + "\n");
    }

private static long testeLength(String s, long iteracoes)
    {
        long t1, t2, i;
        
        t1 = System.currentTimeMillis();
        for (i = 0; i < iteracoes; i++)
            if (s.length() == 0);
        t2 = System.currentTimeMillis();
        
        return t2 - t1;        
    }
    
    private static long testeEquals1(String s, long iteracoes)
    {
        long t1, t2, i;
        
        t1 = System.currentTimeMillis();
        
        for (i = 0; i < iteracoes; i++)
            if (s.equals(""));
        
        t2 = System.currentTimeMillis();
        
        return t2 - t1;        
    }

private static long testeEquals2(String s, long iteracoes)
    {
        long t1, t2, i;
        
        t1 = System.currentTimeMillis();
        
        for (i = 0; i < iteracoes; i++)
            if ("".equals(s));
        
        t2 = System.currentTimeMillis();
        
        return t2 - t1;        
    }
    
    private static long testeIsEmpty(String s, long iteracoes)
    {
        long t1, t2, i;
        
        t1 = System.currentTimeMillis();
        
        for (i = 0; i < iteracoes; i++)
            if (s.isEmpty());
        
        t2 = System.currentTimeMillis();
        
        return t2 - t1;        
    }
}

100 milhões de iterações, em milissegundos:

Edit 2: Corrigido o benchmark
Edit 3: Refatorado o benchmark

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Editei o post acima.

This message was edited 2 times. Last update was at 30/04/2008 10:18:17

Tem algo errado nesse seu benchmark.

Veja só, o método isEmpty está implementado assim:
return count == 0;

Isso é exatamente o que faz o seu teste com length.
Alguém saberia explicar pq ele tem a mesma performance do equals?

De qualquer forma, ele vem a provar que a performance desses métodos é tão boa, que dificilmente eles ocasionariam problemas de performance para essa situação.

Erro na linha 16!

Você está chamando o método testeEquals2 e não o testeIsEmpty...

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Corrigi o benchmark. Agora ele faz só médias.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

ViniGodoy wrote:

sergiotaborda wrote:

ViniGodoy wrote:
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).

Não. "abc" e "def" têm o mesmo length. Só se o tamanho é igual é que se tem que passar a uma analise caracter a caracter. Os outros testes são otimizações. O segundo teste tb teste o null. Nem sempre vai ser uma string

Sérgio, estou falando do teste:
!string.equals("")

Que foi proposto pela Lina, no início do tópico. Não tem absolutamente nada a ver com coleções.

E, como mostrado no código fonte da classe String (está no início do tópico), são feitas 3 comparações, sendo 2 delas desnecessárias.

A primeira, verifica se o objeto recebido no parâmetro e o this são exatamente o mesmo objeto. No caso desse exemplo, as chances disso ocorrer são ridiculamente pequenas.

Sim. Mas vc escreveu "o que nunca vai ocorrer"

lol
Agora eu entendi que vc estava falando do caso especifico de string.equals(""). Peço desculpas se o ofendi.

Interessante... o

Demora mais que o

Por que isso??

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.

Foxlol,

Conforme sugere o método java.lang.String#intern(), acredito que no caso específico da String "", ela já esteja na memória através do pool de Strings mantido pela própria classe, não onerando assim a memória ao instanciar mais um objeto.

ViniGodoy wrote: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):
public int length() { return count; }

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).

public boolean equals(Object anObject) { if (this == anObject) { //Comparação 1 return true; } if (anObject instanceof String) { //Comparação 2 String anotherString = (String)anObject; int n = count; if (n == anotherString.count) { //Comparação 3 char v1[] = value; char v2[] = anotherString.value; int i = offset; int j = anotherString.offset; while (n-- != 0) { if (v1[i++] != v2[j++]) return false; } return true; } } return false; }

Usando o equals é ainda mais recomendado colocar a constante na frente, assim:
if (!"".equals(string))

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.

ViniGodoy,

Conforme falei acima, se vc olhar o javadoc do método java.lang.String#intern(), a primeira comparação se faz necessária, pois o objeto pode estar no pool de Strings mantido pela própria classe.

Quanto a vc afirmar que a segunda comparação tbm será sempre verdadeira, tbm discordo... O método equals espera um Object, então qualquer coisa pode ser passada e em um projeto com muitos estagiários você pode ver a invocação do método equals de uma String recebendo como parâmetro um Double, por exemplo.

Já a terceira comparação não entendi pq vc afirmou ser possível somente para String vazia.

This message was edited 3 times. Last update was at 24/05/2011 13:18:06

Observe que falei que é "nessa situação específica". Ele estava querendo testar se uma string era vazia através da comparação "".equals(string) - Aliás, isso também é explicado para o sergio taborda bem no início do post onde vc fez quote.

No caso dessa comparação é muitíssimo raro que a string recebida seja igual idêntica a String vazia (passe no ==). O método intern pode garantir isso, mas ele também exige custo computacional, e muito maior que o do equals. Como ele também disse que passaria uma string por parâmetro, sabíamos que não se tratava de outra classe.

É por isso mesmo que o método equals é mais lento que o length para testar String vazia. Por que ele:
a) Se previne contra o uso incorreto (já que pode receber um object);
b) Testa se os objetos são idênticos (o que normalmente não vai ocorrer).

No caso, o length não precisa fazer nada disso.

Em todo caso, desde o Java 6, essa dúvida já não existe mais. Inseriram o método isEmpty() na classe String. Por isso que não é muito saudável ressuscitar discussões de 2008. E, lógico, sua implementação baseia-se no length().

Não estou falando que a implementação do equals é errada. Na verdade, esses fatores são otimizações para quando se quer testar se duas strings são iguais. Porém, isso não quer dizer que elas sejam eficientes para testar o vazio. E, como eu já disse outras vezes no tópico, a diferença de 1 if para 3 ifs em termos de performance é apenas acadêmica pois, na prática, dificilmente isso aí constituirá um gargalo de performance em qualquer aplicação comercial.

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