Modificador static nos metodos, codigo mais rapido ?

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

Ola thingol,

Opa, me confundi, e Reflaction que quiz dizer mesmo!!

O Reflaction utiliza o mesmo processo de carga que um static? Pois os dois sao cargas de classes feitas pela VM na memória...

abraços

This message was edited 2 times. Last update was at 14/01/2009 10:56:33

thingol wrote:Você está confundindo "refactoring" com "reflection". (....)....
classes anônimas e temporárias pela JVM. Depois do almoço eu digo como é que a reflection é implementada.

Acho que depois do almoço o Thingol vai explicar melhor reflection sobre static..... vamos esperar.... ; )

JavaTeenager Membro desde: 02/06/2008 10:31:11 Mensagens: 185 Offline

joaosiqueira wrote:
...
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!!
...

Utilizar 'static' em todo o seu programa muito provavelmente não melhorará sua performance - é provável que, devido à falta de orientação a objetos em uma linguagem orientada a objetos, seus algoritmos fiquem cada vez mais complexos, difíceis de entender e conseqüentemente mais lentos. Uma arquitetura bem feita leva em consideração a passagem de mensagens entre um método e outro - possivelmente reduzindo o trabalho do GC, um dos pontos citados por você.

A melhor maneira de obter uma melhor performance é otimizar os algoritmos e estruturas de dados do programa em seus pontos críticos, o que se sabe através de um processo de 'profiling'. Se você quer se aprofundar (muito) mais, pega um decompiler e analisa o bytecode pra ver como as instruções são traduzidas e executadas - isso pode lhe mostrar muita coisa sobre sua maneira de programar. Não adianta nada você fazer um programa baseado em métodos estáticos se você fica dando loops e enchendo buffers toda hora... além do que se você precisa de 'performance ao limite', Java não é a linguagem que você quer: apele ao clássico C ou ao Assembly mesmo...

Virtual Machine Man Membro desde: 04/07/2007 18:28:58 Mensagens: 824 Offline

joaosiqueira wrote: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

Uma coisa tem que ficar clara: você não vai conseguir economizar memória usando static. Numa situação hipotética onde toda a sua estrutura de dados está armazenada de maneira estática (dica: você não vai conseguir), todos os recursos estarão alocados, mesmo que você não esteja utilizando boa parte deles no momento.

Linguagens orientadas a objeto te incentiva a criar e destruir objetos dinamicamente, fazendo com que, num determinado momento, você só tenha os objetos (e por consequencia, memória) que precisa.

This message was edited 1 time. Last update was at 14/01/2009 11:48:19

MarceloS wrote:
A melhor maneira de obter uma melhor performance é otimizar os algoritmos e estruturas de dados do programa em seus pontos críticos, o que se sabe através de um processo de 'profiling'. Se você quer se aprofundar (muito) mais, pega um decompiler e analisa o bytecode pra ver como as instruções são traduzidas e executadas - isso pode lhe mostrar muita coisa sobre sua maneira de programar. Não adianta nada você fazer um programa baseado em métodos estáticos se você fica dando loops e enchendo buffers toda hora... além do que se você precisa de 'performance ao limite', Java não é a linguagem que você quer: apele ao clássico C ou ao Assembly mesmo...

Você esta colocando isso sobre CVS não entendi ? Quanto a otimizar os algoritmos e estruturas de dados, você diz ao ponto críticos a atráves de profiling ou atráves de instrumentação pela VM...... algo como JSON no JBoss pode dar melhor exemplo.....

This message was edited 1 time. Last update was at 14/01/2009 11:48:57

?

Virtual Machine Man Membro desde: 18/09/2006 10:05:46 Mensagens: 534 Offline

Marcio Duran wrote:

thingol wrote:Você está confundindo "refactoring" com "reflection". (....)....
classes anônimas e temporárias pela JVM. Depois do almoço eu digo como é que a reflection é implementada.

Acho que depois do almoço o Thingol vai explicar melhor reflection sobre static..... vamos esperar.... ; )

Quero ver isso também...

Inté.

JavaTeenager Membro desde: 02/06/2008 10:31:11 Mensagens: 185 Offline

Marcio Duran wrote:
Você esta colocando isso sobre CVS não entendi ? Quanto a otimizar os algoritmos e estruturas de dados, você diz ao ponto críticos a atráves de profiling ou atráves de instrumentação pela VM...... algo como JSON no JBoss pode dar melhor exemplo.....

CVS? O que que controle de versão tem a ver?

E sobre as estruturas de dados estava me referindo a utilizar as estruturas adequadas ao caso: já vi muita gente que ainda usa Vector, ou usa uma List e procura dentro de um for pra achar o elemento quando podia usar um Map... só de exemplos mais básicos.

Virtual Machine Man Membro desde: 13/01/2005 12:31:27 Mensagens: 717 Offline

Os métodos de instância também são compartilhados por todas as instâncias. Não tem sentido a VM manter cópias idênticas dos métodos.

This message was edited 1 time. Last update was at 14/01/2009 22:30:43

joaosiqueira wrote:Mas nesse momento nao teriamos que concordar com o ccaneta?

ccaneta wrote:
Acho que uma instancia "new" pode gastar mais memoria do que fazer uma chamada static direto.

Mas nao tenho certeza disso, vcs que me corrijam se estiver enganado.

Aqui são dois problemas diferentes. Instanciar vários objetos na memória a toa, com certeza é ruim. Mas isso não significa que todas as chamadas devem ser estáticas. Afinal, não há desperdício de memória em criar objetos apenas quando é necessário e invocar os métodos não-estáticos deles.

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?

Ou você não entendeu a minha resposta ou eu não entendi a sua dúvida.
Cada classe é carregada uma única vez na memória durante a execução. A JVM não carrega nunca a mesma classe duas vezes. A classe é carregada porque acontece mais ou menos isso:

Programa: Ei JVM, quero chamar o método Foo da classe Bar.
JVM: Bem, ainda não carreguei a classe Bar. Espera um pouquinho que eu vou montá-la aqui.
[JVM carrega a classe Bar]
JVM: Ok, terminei de carregar a classe, agora vou chamar o Foo.
[JVM chama o método Foo]
Programa: Legal. Agora chame o método Abc da classe Bar.
JVM: Ok, como eu já carreguei a classe antes, é só chamar o método.
[JVM chama o método Abc]

Um exemplo:

joaosiqueia wrote:1 processo e mais rapido que 2....

Não é bem assim. Aquilo que escrevi foi de um modo simples. A JVM tem alguns truques em baixo da manga para acelerar as coisas, de forma que ela possa eliminar a verificação de instância = null se ela perceber que não existe forma daquilo ser null. Além disso, em muitos casos o uso de static pode também deixar o código mais lento, porque objetos alcançáveis por meio de atributos estáticos não podem ser recolhidos pelo coletor de lixo e podem causar desperdício de memória e em casos extremos lentidão devido ao swap. Como atributos de instância não são acessíveis em métodos estáticos, você acabaria preso aos métodos estáticos.

Além disso, atributos estáticos são uma grande dor de cabeça em programas com mais de uma Thread (e se você precisa muito de desempenho, provavelmente terá mais de uma Thread rodando). Várias Threads acessando atributos estáticos concorrentemente sem a devida sincronização cria toda a (má) sorte de condições de corridas que resultam em erros obscuros, difíceis de reproduzir e de ocorrência aleatória e misteriosa, justamente aqueles que são os maiores pesadelos na hora do debug. Para que várias Threads possam acessar atributos estáticos concorrentemente sem estes problemas, você vai precisar de sincronização ou na melhor das hipóteses colocar os atributos como volatile, mas qualquer uma destas abordagens é mais custosa do que transformar o atributo em atributo de instância.

Mais além, a JVM é capaz de fazer otimizações melhores quando ela sabe que o objeto vai ficar restrito a um único local, coisa que não é a cara de atributos estáticos.

E repetindo, eu falei tudo isso sobre atributos estáticos porque há pouco sentido em se ter atributos de instância sem ter métodos de instância. Além disso, o acesso aos atributos de uma instância A de dentro de um método de instância de A tende a ser melhor otimizado do que o acesso a um atributo (de instância) de A dentro de um método estático ou de um método da instância B. Isso ocorre porque a JVM pode otimizar o acesso ao ponteiro this.
Ok, ela também pode otimizar o acesso aos atributos estáticos da mesma classe, mas isso ainda não resolve o problema.

eu mesmo wrote:Mas seja lá qual for este tempo, ele deve ser ínfimo e desprezível. Se você está tão desesperado por desempenho que isto pode lhe fazer diferença, então você nem devia estar programando em java, e sim em assembler (ou até no hardware).

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

Victorwss,

Sua explicaçao foi demais, tenho q admitir... gostei!

Em que momentos vc acha que deveria utililizar um metodo static? Pois atualmente utilizo em metodos de classe de serviços de negocio, classes utilitarias e algumas vezes em blocos static para inicializaçao de valores.

O processo de carga de uma classe em uma Reflection e o mesmo que um static? Pois sempre dizemos que uma Reflection e lento, e o melhor seria utilizar o new diretamente no código em tempo de compilçao e nao execuçao.

Obrigado pela força!
abraços

joaosiqueira wrote:Victorwss,

Sua explicaçao foi demais, tenho q admitir... gostei!

Em que momentos vc acha que deveria utililizar um metodo static? Pois atualmente utilizo em metodos de classe de serviços de negocio, classes utilitarias e algumas vezes em blocos static para inicializaçao de valores.

O processo de carga de uma classe em uma Reflection e o mesmo que um static? Pois sempre dizemos que uma Reflection e lento, e o melhor seria utilizar o new diretamente no código em tempo de compilçao e nao execuçao.

Obrigado pela força!
abraços

Não existe regra receita-de-bolo para saber se um método deveria ser estático ou não. Mas há algumas diretrizes.

Prefira os métodos de instância. O static é uma coisa que normalmente vai contra a OO, mas por vezes ele é necessário. Na dúvida prefira os métodos de instância. Só use o static quando você realmente tiver certeza que não precisa e nem nunca precisará da instância e nem do polimorfismo.

Reflection serve para manipular classes, métodos e atributos que você normalmente só vai saber quais são durante a execução. Se você pode saber quais são em tempo de compilação, então não há muito sentido em usar reflection.

Forum Spammer Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

joaosiqueira wrote:
Em que momentos vc acha que deveria utililizar um metodo static? Pois atualmente utilizo em metodos de classe de serviços de negocio, classes utilitarias e algumas vezes em blocos static para inicializaçao de valores.

"Para qual paradigma você esta se referindo", onde você trabalhar esses metodos de serviços para SOA engine ?

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

Ola Marcio Duran,

Os serviços em que me refiro fiz sao classes POJO.

Vc tb utiliza static em serviços SOA?

abraços

This message was edited 1 time. Last update was at 15/01/2009 12:44:19

joaosiqueira wrote:Ola Marcio Duran,

Os serviços em que me refiro fiz sao classes POJO.

Vc tb utiliza static em serviços SOA?

abraços

"É hacker te peguei"

POJO Service Engine

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