Multiplos de 3 de 1 a 100

Smalltalk Membro desde: 11/03/2009 13:40:07 Mensagens: 1 Offline

Ola pessoal estou a estudar as apostilas da caelum e tou com duvidas neste exercicio que axo que nao fiz da melhor maneira e agradecia que me explicassem melhor se possivel obrigado.

Thread.start() Membro desde: 11/06/2006 22:43:37 Mensagens: 35 Offline

Você quer um algoritmo melhor para imprimir os múltiplos de 3 entre 1 e 100?
Eu usaria módulo.

This message was edited 2 times. Last update was at 12/03/2009 16:31:00

Não sei qual é a intensão do exercício e não entendi sua dúvida... mas vai um exemplo:

Java Ninja Membro desde: 17/08/2006 14:55:20 Mensagens: 299 Offline

O código do rdgc é o mais eficiente. Por módulo tb está correto, mas vc faz mais cálculos e ainda tem um if. Não q seja o fim do mundo, mas só p vc entender.

Nem tudo é como parecer ser!

Se vocês pretendem deixar o código otimizado ao máximo, devem fazer apenas uma chamada de sistema operacional para imprimir na tela. Para isso precisa armazenar o resultado em memória para depois imprimir apenas uma vez. Utilizar String para isso é inviável em termos de performance, pois ela é imutável. StringBuffer é a classe eficaz para concatenar muitas Strings, pois ela é mutável. StringBuilder faz a mesma coisa, só que previne a concatenação ao objeto de duas ou mais Threads, nesse exemplo não é nececessária pois existe só a Thread padrão que executa o método main().

Eis o código:Para computar e imprimir todos múltiplos de 3 de 1 até 10.000 levou-se 234 milisegundos.

Para aquele código inicial:Para computar e imprimir todos múltiplos de 3 de 1 até 10.000 levou-se 953 milisegundos.

Para aquele código incrementando de três em três:Para computar e imprimir todos múltiplos de 3 de 1 até 10.000 levou-se 938 milisegundos.

Claro que esses tempos podem variar de acordo com a preempção da Thread que executa o código. Mas pelo que vocês podem ver, imprimir na tela uma vez sequer é muito, muito, muito mais lento do que uma simples otimização de incremento.

This message was edited 1 time. Last update was at 12/03/2009 23:23:06

Sua mensagem está meio certa. Primeiro:
- Sim, fazer uma só chamada ao SO torna o seu código mais rápido.
- Agora é quase que falácia dizer que concatenar Strings é mais lento que usar StringBuffer/StringBuilder. Quer saber por que? Aprenda a usar o javap.

Até!

This message was edited 2 times. Last update was at 12/03/2009 23:52:36

maquiavelbona wrote:
- Agora é quase que falácia dizer que concatenar Strings é mais lento que usar StringBuffer/StringBuilder.

Se for quase que falácia, então me explique pq esse código com StringBuffer roda em 47ms.

E me explique pq esse código abaixo que concatena strings roda em 11422ms.

Como se vê, é concatenação em Strings versus concatenação em StringBuilder.

Ainda não enxerguei nenhuma falácia no que eu disse.

This message was edited 1 time. Last update was at 13/03/2009 07:33:26

This message was edited 7 times. Last update was at 13/03/2009 08:17:54

dionat4n wrote:StringBuilder faz a mesma coisa, só que previne a concatenação ao objeto de duas ou mais Threads

Você trocou as bolas ao explicar do StringBuffer e do StringBuilder nesse caso. O StringBuffer é sincronizado e previne o acesso concorrente, e o StringBuilder, não. Portanto, corrija os seus exemplos para usar o StringBuilder, não o StringBuffer. Veja o que diz a documentação do StringBuffer:
"As of release JDK 5, this class has been supplemented with an equivalent class designed for use by a single thread, StringBuilder. The StringBuilder class should generally be used in preference to this one, as it supports all of the same operations but it is faster, as it performs no synchronization."

Na prática, raramente você utilizará o StringBuffer, pois o acesso concorrente a um único buffer raramente faz sentido. A sincronização só previne que o método append() não seja chamada por duas threads simultâneas, porém, ela não garante nada sobre o que acontece entre duas chamadas ao método append. Por exemplo, se o código
strBuf.append("15/09/1980 ").append("log line ");

For executado por duas threads diferentes a saída poderá ser "15/09/1980 log line 15/09/1980 log line" ou poderá ser "15/09/1980 15/09/1980 log line log line". O que ela não poderá ser (já que o StringBuffer é sincronizado) é "15log/09/li19ne80 15log/09/li19ne80 ".

A solução para isso é sincronizar a classe que contém o StringBuffer, mas nesse caso, a sincronização do buffer em si torna-se desnecessário, e podemos substitui-lo por um stringBuilder.

A concatenação de Strings realmente é mais rápida com essas classes. Ela só não é mais rápida em casos assim:

Que o java irá substituir invariavelmente por:

Mas, realmente, dentro de um while o tempo é incomparavelmente menor, como você mesmo demonstrou.

Outra coisa que eu notei...

Já que você está usando o StringBuilder, não use a contatenação dentro do método append, foi feito na linha 7 do programa:

Dessa forma, você pode voltar a incorrer nos custos que queria evitar. No lugar, use o método append do próprio StringBuilder. Uma característica interessante é que esse método retorna o próprio StringBuilder, o que permite-nos chamar em cadeia:

Melhor que isso, só se a Sun tivesse escolhido a palavra add no lugar de append...

This message was edited 1 time. Last update was at 13/03/2009 07:57:44

ViniGodoy wrote:

dionat4n wrote:StringBuilder faz a mesma coisa, só que previne a concatenação ao objeto de duas ou mais Threads

Você trocou as bolas ao explicar do StringBuffer e do StringBuilder nesse caso. O StringBuffer é sincronizado e previne o acesso concorrente, e o StringBuilder, não. Portanto, corrija os seus exemplos para usar o StringBuilder, não o StringBuffer. Veja o que diz a documentação do StringBuffer:
"As of release JDK 5, this class has been supplemented with an equivalent class designed for use by a single thread, StringBuilder. The StringBuilder class should generally be used in preference to this one, as it supports all of the same operations but it is faster, as it performs no synchronization."

Na prática, raramente você utilizará o StringBuffer, pois o acesso concorrente a um único buffer raramente faz sentido. A sincronização só previne que o método append() não seja chamada por duas threads simultâneas, porém, ela não garante nada sobre o que acontece entre duas chamadas ao método append. Por exemplo, se o código
strBuf.append("1").append("2");

For executado por duas threads diferentes a saída poderá ser 1212 ou poderá ser 1122.

A solução para isso é sincronizar a classe que contém o StringBuffer, mas nesse caso, a sincronização do buffer em si torna-se desnecessário, e podemos substitui-lo por um stringBuilder.

A concatenação de Strings realmente é mais rápida com essas classes. Ela só não é mais rápida em casos assim:

String nomeCompleto = titulo + nome + sobrenome + complemento;

Que o java irá substituir invariavelmente por:
String nomeCompleto = new StringBuilder(titulo).append(nome).append(sobrenome).append(complemento);

Mas, realmente, dentro de um while o tempo é incomparavelmente menor, como você mesmo demonstrou.

Não troquei as bolas não.

Evitar o acesso concorrente para concatenação no objeto é a mesma coisa que evitar a concatenação ao objeto de duas ou mais Threads ( ao mesmo tempo! esqueci de escrever isso...

)

ViniGodoy wrote:Outra coisa que eu notei...

Já que você está usando o StringBuilder, não use a contatenação dentro do método append, foi feito na linha 7 do programa:
sb.append(i + quebraLinha);

Dessa forma, você pode voltar a incorrer nos custos que queria evitar. No lugar, use o método append do próprio StringBuilder. Uma característica interessante é que esse método retorna o próprio StringBuilder, o que permite-nos chamar em cadeia:
sb.append(i).append(quebraLinha);

Melhor que isso, só se a Sun tivesse escolhido a palavra add no lugar de append...

Com certeza, eu até iria fazer isso, mas daí ficaria diferente do programa anterior, pois eu queria adicionar strings propriamente dito.

Ué, se não trocou as bolas, porque seu código está com o StringBuffer, e não o StringBuilder, quando a documentação diz que é justamente o contrário que se deve fazer?

Sua explicação está trocada sim cara. Leia o Javadoc.

ViniGodoy wrote:Ué, se não trocou as bolas, porque seu código está com o StringBuffer, e não o StringBuilder, quando a documentação diz que é justamente o contrário que se deve fazer?

Sua explicação está trocada sim cara. Leia o Javadoc.

Viajei total! hauehuaehuea
É verdade, troquei as bolas...
Se bem que quem nomeou essas classes poderia colocar algo mais sugestivo...

Valeu!

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