[quote=nickdofeliperibeiro]entanglement,
Você está correto!
O ganho de perfomace está em você não alocar tantos objetos na heap e exigir que o GC trabalhe limpando essas &refs.
Certo?
Obrigado![/quote]
Neste caso em particular talvez.
Eu ainda fico pasmado de ver que é possível criar 20 milhões de objetos por segundo (que é o caso desse loop com strings em vez de comparar 2 arrays “estáticos” de char - eu chamo de “estáticos” porque estou reusando sempre os mesmos) e o Garbage Collector ainda conseguir limpá-los eficaz e corretamente.
É que nesse programa em particular até dá para evitar a criação de objetos. Mas em geral, em Java, não fique tentando reaproveitar objetos, que não vale a pena.
Pois é… A velocidade de processamento realmente é absurda!
Na verdade minha preocupação não foi em reuso, e sim o uso da memória.
Hoje em dia não é hábito se preocupar com isto por termos, por exemplo, bastante memória para usar.
Mas imagine, um dia você ter que programar em um CI (circuito integrado) que tenha pouca memória para esse tipo de alocação?!
O meu argumento realmente é muiito específico. Mas foi só um destaque para nos atentarmos a isso!
Obrigado pelo conhecimento camarada!
Se a forma do entanglement ainda não for o suficiente, talvez o próximo passo da otimização seja tornar programa mais específico.
Se você sabe que a senha foi gerada por pessoas, ao invés de simplesmente tentar todos os valores possíveis, você pode tentar implementar o algorítmo do dicionário. Assim, você primeiro testa palavras da lingua de origem da pessoa, depois combinações dessas palavras para só então partir para força bruta simples.
Fica melhor ainda se você conhecer o alvo, e colocar também datas de aniversário, casamento, nascimento dos filhos, dos pais, da esposa, nome do cachorro…
Só a título de curiosidade. Eu implementei em C++ o algorítmo de Bresenham. O algorítmo estava desenhando sobre uma superfície de software da SDL.
Rodando ele num QuadCore i7 de 3.07Ghz, sem usar multiplas threads, consegui desenhar 600.000 linhas coloridas por segundo.
As linhas tinham em torno de 500 pixels de comprimento (são aproximadamente 300 milhões de pixels pintados por segundo).
As máquinas hoje em dia são mesmo muito rápidas.
Sua preocupação é bastante válida. Se isso fosse linguagem C++ e ele estivesse dando new e delete.
No Java, mesmo com o new daqueles, o garbage collector reusa memória. Tem um artigo bem interessante sobre isso do Goetz:
O interessante é que um programa que faça muito new e delete é o que eu geralmente uso de exemplo naqueles tópicos de flame quando os fãs de C++ dizem que o Java é mais lento que o C++. :mrgreen:
Um programinha assim:
int i = 0;
int soma = 0;
for (int i = 0; i < 10000; i++)
Classe c = new Classe(i);
soma += c.getValor(); //Retorna i
delete c;
}
std::cout << soma << std::endl;
Roda milhares de vezes mais lento em C++ do que em Java, justamente por essa capacidade mágica do GC de reaproveitar a memória de objetos de vida curta. 
Já o C++, perde muito tempo criando e apagando o objeto do heap (claro, um programador C++ mais “cabelos no peito” poderia escrever seu próprio alocador e deixar o java comendo poeira).
PS: O cálculo da soma só está ali para evitar que o compilador elimine o código por considera-lo “morto”.
Sua preocupação é bastante válida. Se isso fosse linguagem C++ e ele estivesse dando new e delete.
No Java, mesmo com o new daqueles, o garbage collector reusa memória. Tem um artigo bem interessante sobre isso do Goetz:
O interessante é que um programa que faça muito new e delete é o que eu geralmente uso de exemplo naqueles tópicos de flame quando os fãs de C++ dizem que o Java é mais lento que o C++. :mrgreen:
Um programinha assim:
int i = 0;
int soma = 0;
for (int i = 0; i < 10000; i++)
Classe c = new Classe(i);
soma += c.getValor(); //Retorna i
delete c;
}
std::cout << soma << std::endl;
Roda milhares de vezes mais lento em C++ do que em Java, justamente por essa capacidade mágica do GC de reaproveitar a memória de objetos de vida curta.
Já o C++, perde muito tempo criando e apagando o objeto do heap (claro, um programador C++ mais “cabelos no peito” poderia escrever seu próprio alocador e deixar o java comendo poeira).
PS: O cálculo da soma só está ali para evitar que o compilador elimine o código por considera-lo “morto”.[/quote]
Mas a pessoa que sabe escrever em c++ iria usar a stack na maioria dos casos do que partir para alocação dinâmica e guardar essas classes na heap.
int i = 0;
int soma = 0;
for (int i = 0; i < 10000; i++)
Classe c (i);
soma += c.getValor(); //Retorna i
delete c;
}
std::cout << soma << std::endl;
Como você disse alocar dinamicamente em c++ não é tão eficiente quanto em java. Então o trabalho de otimizar o código acaba sendo nosso mesmo. Acho que desse jeito fica tão rápido quanto o java.