Modificador static nos metodos, codigo mais rapido ?

GUJ Master Membro desde: 23/10/2008 06:39:07 Mensagens: 1001 Offline

Mauricio Linhares wrote:

joaosiqueira wrote:Thingol,

Entao podemos dizer que qdo eu faço uma Reflection de uma classe, estou carregando da mesma forma que um static faz?

Se eu pensar neste modelo, sempre que dizer que um Reflection e mais lento do que dar um new, certo?? Teria que dizer que o static e mais lento tb, nao e?

O que vc acha disso?

Impressão minha ou esse cara escreve feito o Márcio Duran?

Impressão minha ou ele é um fake do Mr. Duran Duran?

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

joaosiqueira wrote:victorwss,

Muito boa boa sua explicaçao, gostei mesmo.

Mas nesse momento nao teriamos que concordar com o ccaneta?

Quando diz que o fato de usar uma classe carregada usaria menos memoria e evitaria o tempo de instanciar uma classe, ao contrario do new em que temos que carregar e depois instanciar?

Pensando assim usar um static seria mais vantajoso?
Eu penso logicamente que 1 passo e sempre mais rapido que 2 passos, agora nao sei a opiniao de voces em relaçao a isso..

O que vcs opinam?

Um passo é mais rápido que dois passos, obviamente. Mas sua aplicação não rodará duas vezes mais rápido só porque você teve preguiça de usar OO e usou static em tudo quanto é quanto. O motivo é simples: a instanciação de objetos não é parte mais custosa de aplicação. O que é custoso é mandar queries no banco de dados, escrever arquivos, enviar dados via rede, fazer serialização, parsear XML... Ou seja, instanciar ou não objetos é coisa ínfima, perto de muitas outras coisas.

E eu já falei que não é recomendável usar variáveis estáticas em ambiente Java EE, devido aos múltiplos classloaders, não falei? Sabia que há problema na serialização de objetos quando a variável é estática? Lembre-se também que muitos containeres dependem que seus métodos não sejam estáticos.

Então qual é o ponto? Você quer provar que orientação a objetos não vale a pena?

Thread.start() Membro desde: 08/01/2009 08:23:56 Mensagens: 40 Offline

Leonardo3001 wrote:
Um passo é mais rápido que dois passos, obviamente. Mas sua aplicação não rodará duas vezes mais rápido só porque você teve preguiça de usar OO e usou static em tudo quanto é quanto. O motivo é simples: a instanciação de objetos não é parte mais custosa de aplicação. O que é custoso é mandar queries no banco de dados, escrever arquivos, enviar dados via rede, fazer serialização, parsear XML... Ou seja, instanciar ou não objetos é coisa ínfima, perto de muitas outras coisas.

Leonardo3001,

Nao estamos pensando em fatores de midleware, somente num simples trecho de codigo java ao maximo da performance...

Pelo que vejo, vc ja esta concordando comigo em alguma coisa:
1 processo e mais rapido que 2....

Portanto se com um metodo static eu evito um processo de instanciaçao, vemos que um static por mais desaconselhavel de praticas de design, J2EE e etc, e mais rapido e nao podemos negar!

Quando vamos começar a pensar que o simples gera o avançado, e nao pensar que nem sempre temos memoria em todos os dispositivos.. ja pensou se um aplicativo java da Nasa pudesse usar o que um simples cadastro exige num mero PC!!

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

AUser wrote: Impressão minha ou ele é um fake do Mr. Duran Duran?

Essa aula de Static e Refletion já vai ser bom pro seu curriculum hein... mais ainda Heap e Stack são assuntos basico até para certificação Java hein.... ; )

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

joaosiqueira wrote:

Leonardo3001 wrote:
Um passo é mais rápido que dois passos, obviamente. Mas sua aplicação não rodará duas vezes mais rápido só porque você teve preguiça de usar OO e usou static em tudo quanto é quanto. O motivo é simples: a instanciação de objetos não é parte mais custosa de aplicação. O que é custoso é mandar queries no banco de dados, escrever arquivos, enviar dados via rede, fazer serialização, parsear XML... Ou seja, instanciar ou não objetos é coisa ínfima, perto de muitas outras coisas.

Leonardo3001,

Nao estamos pensando em fatores de midleware, somente num simples trecho de codigo java ao maximo da performance...

Pelo que vejo, vc ja esta concordando comigo em alguma coisa:
1 processo e mais rapido que 2....

Portanto se com um metodo static eu evito um processo de instanciaçao, vemos que um static por mais desaconselhavel de praticas de design, J2EE e etc, e mais rapido e nao podemos negar!

Quando vamos começar a pensar que o simples gera o avançado, e nao pensar que nem sempre temos memoria em todos os dispositivos.. ja pensou se um aplicativo java da Nasa pudesse usar o que um simples cadastro exige num mero PC!!

Não realidade, quando concordo que "um é mais rápido que dois", não implica que concordo que static é mais rápido que dar new. Na verdade, não tenho a inteligência do Kumpera para detalhes do baixo nível do Java. Tudo que sei é que, pela minha experiência, não há diferenças, para o usuário, entre uma aplicação que usa static de outra que não usa.

J2EE não é só para middleware. A maioria das pessoas usam a plataforma para fazer aplicações web também.

Quando não se tem memória, deve-se evitar usar muitos recursos, só isso, não tem nada a ver fazer instanciação ou não. Outra, otimizações locais não resultam em grandes melhorias no resultado final. Otimizar é pensar globalmente, na aplicação como um todo, não em detalhes irrelevantes de baixo nível.

Aplicações da Nasa, ou até do Google, tem requisitos tão especiais que acredito que eles utilizam só a linguagem Java, a plataforma é proprietária feita por eles mesmos. Mas ainda assim, acho impossível eles sugerirem que se deva usar static ao invés de instanciar objetos.

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

Leonardo3001 wrote:
Aplicações da Nasa, ou até do Google, tem requisitos tão especiais que acredito que eles utilizam só a linguagem Java, a plataforma é proprietária feita por eles mesmos. Mas ainda assim, acho impossível eles sugerirem que se deva usar static ao invés de instanciar objetos.

Você não consegui relacionar static com SOA ,você sabe como isso fuciona ?

JWizard Membro desde: 18/02/2008 16:17:53 Mensagens: 2981 Offline

joaosiqueira wrote:
Portanto se com um metodo static eu evito um processo de instanciaçao, vemos que um static por mais desaconselhavel de praticas de design, J2EE e etc, e mais rapido e nao podemos negar!

Numa análise fria, nestes termos super-simplificados, sim, static é mais rápido.

E quem vir essa frase acima e for usar static pra tudo, e digo parabéns. Parabéns por ferrar com toda a arquitetura do teu projeto p/ ganhar alguns microsegundos. Ou parabéns por usar uma arquitetura totalmente procedural numa linguagem orientada a objetos, e ignorar todos os outros recursos úteis da linguagem.

A discussão foi ótima com toda a explicação técnica do que acontece nos bastidores, útil para quem quiser fazer algo extremamente avançado e específico. Para o resto, isso só serve para inflar o ego pra dizer que estavam certos, mesmo que não tenha a mínima importância na vida deles.

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

Bruno Laturner wrote:Numa análise fria, nestes termos super-simplificados, sim, static é mais rápido.

E quem vir essa frase acima e for usar static pra tudo, e digo parabéns. Parabéns por ferrar com toda a arquitetura do teu projeto p/ ganhar alguns microsegundos. Ou parabéns por usar uma arquitetura totalmente procedural numa linguagem orientada a objetos, e ignorar todos os outros recursos úteis da linguagem.(.....................)................................

In object-oriented Java were a great improvement over the procedural paradigm (Naturalmente isso é baseado em que Arquitetura estamos falando se Framework) ou se ERP´s,ou você quer discutir OFBIZ ?,pois nessa tecnologia existem serviços static, você sabia ????

Thread.start() Membro desde: 08/01/2009 08:23:56 Mensagens: 40 Offline

Bruno Laturner wrote:
E quem vir essa frase acima e for usar static pra tudo, e digo parabéns. Parabéns por ferrar com toda a arquitetura do teu projeto p/ ganhar alguns microsegundos. Ou parabéns por usar uma arquitetura totalmente procedural numa linguagem orientada a objetos, e ignorar todos os outros recursos úteis da linguagem.

Bruno,

Acredito que a razao aqui nao e provar nada para ninguem dizendo vc esta certo ou errado, e apenas buscar uma melhor soluçao num momento critico...
No mundo de TI, existem momentos em que termos a melhor arquitetura e a melhor saida.. mas como digo, existem outros momentos em que queremos somente perfomance ao limite!!

Ai nao adianta botarmos patterns, patterns, pq o que vai deixar rapido de verdade é o código simples ao extremo e quanto mais estruturado melhor! Como um profissional de TI posso lhe garantir!

Mas a grande enquente aqui foi, so se um static era mais rápido num metodo, e como podemos concluir isso é verdade! Depois de muita polemica e contradiçao no forum GUJ.

Se pensarmos isso é bonito? Talvez nao, mas se olharmos de outro angulo as vezes e a melhor soluçao, so cabe a vc decidir quando fugir ao extremo.

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17539 Offline

Uma coisa que brasileiro adora é tomar decisões na seguinte base:

- Eu acho que...
- Ouvi falar que...
- Me falaram que...
e a pior:
- Minha opinião é que...

Em vez de fazer experimentos e verificar os números. Nesse caso é relativamente fácil determinar os números.

Como dizia um personagem do Jô Soares, "meu negócio é números".

Então que tal fazer alguns "benchmarks" e ver qual é a diferença de tempo entre usar "static" ou não?

Já vou antecipando que a diferença é desprezível na maior parte dos casos de uso, mas não tomem minha palavra por verdade absoluta.

Thread.start() Membro desde: 08/01/2009 08:23:56 Mensagens: 40 Offline

thingol wrote:
Então que tal fazer alguns "benchmarks" e ver qual é a diferença de tempo entre usar "static" ou não?

Já vou antecipando que a diferença é desprezível na maior parte dos casos de uso, mas não tomem minha palavra por verdade absoluta.

Thingol,

Estou partindo por lógica que 1 passo e mais rápido que 2...
Ai e so a questao de averiguar o quanto mais rápido, mas a lógica sempre vem antes de testar e programar..

Quem nunca ouviu de "tentiva e erro na programaçao", ai quem sofre é o compilador! rs...
:roll:

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

thingol wrote:
Então que tal fazer alguns "benchmarks" e ver qual é a diferença de tempo entre usar "static" ou não?

Não podemos ter intuições ou entender observância sobre o que é o melhor estudo de viabilidade ou escalabilidade de fatores complicadores, você toma decisão através de uma calculadora ciêntifica.

Já vou antecipando que a diferença é desprezível na maior parte dos casos de uso, mas não tomem minha palavra por verdade absoluta.

A verdade absoluta foi negar ao proprio benchmarks, por entender que decisões vão de um entendimento ciêntifico de sua intuição.

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17539 Offline

A lógica diz apenas :

Se vou executar 1 passo em vez de 2, vou gastar menos tempo.

A experimentação diz:

Executar apenas 1 passo, em vez de 2, economiza apenas 0,002% do tempo de processamento*, e não vale a pena.

Não dá para determinar essa porcentagem só por lógica. E pela minha experiência não dá para determinar essa porcentagem nem sabendo exatamente quais são as instruções adicionais que o computador irá executar, porque o tempo de processamento das instruções de máquina é complexo demais para ser calculado com precisão nas máquinas modernas. Antigamente, você poderia saber que uma instrução ADD gastava 4 ciclos de máquina em um microprocessador 8086 e como ele rodava a 4,77 Mhz você saberia que o ADD gastava 4 * (1 / 4770000) segundos = 0,839 microssegundos. Mas hoje em dia isso não pode ser determinado tão simplesmente assim.

* Estou dizendo 0,002, mas obviamente esse tempo tem de ser determinado - é para isso que serve a experiência. Método científico, não é "tentativa e erro", hein?

Thread.start() Membro desde: 08/01/2009 08:23:56 Mensagens: 40 Offline

Qualquer experimentaçao só existe pq alguem usou alguma logica...
A tipica frase: Penso, logo, existo... Uma aula de filosofia eheheh

Enfim, se imaginarmos que num projeto de milhares de classes poderemos evitar uma instanciaçao e poucar memoria e GC ter que ser acionado, pq isso nao seria bem vindo as vezes! Imagina a economia que teriamos

A unica dúvida que fico: O Refactoring utiliza o mesmo processo de carga que um static ?

saudaçoes

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17539 Offline

Você está confundindo "refactoring" com "reflection".

A rigor, o processo de reflection (onde é que a tal "reflection" entrou na história?) é naturalmente um pouco lento (já que envolve obter métodos e classes por nome, em vez de usar suas referências já "prefabricadas"), mas foi devidamente acelerado pela JVM para se tornar útil, a partir do Java 1.4.

Leia um pouco sobre como a reflection foi acelerada pela JVM a partir do Java 1.4 - o processo é um bocado complexo, e envolve a criação de classes anônimas e temporárias pela JVM. Depois do almoço eu digo como é que a reflection é implementada.

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