Modificador static nos metodos, codigo mais rapido ?

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

joaosiqueira wrote:
Mas indiretamente a VM cria uma instancia da classe, pois imagina se vc tem uma variavel membro static... esta fica retida na memoria ate a VM ser derrubada... nao importando se vc cria o objeto via new ou chame via Classe.variavel

Creio que a VM diferencia de alguma forma o static nos metodos e variaveis dos sem.
Se pensarmos no fato de um valor compartilhado permancer na memoria para todas as instancias, podemos imaginar em alguma acelaraçao no codigo por ja estar carregado...

abrs

Não entendo a razão de haver alguma aceleração. Minha impressão: você está tentando argumentar um design ruim (o uso excessivo de static) em nome de uma suposta otimização de desempenho?

Lembre-se: se você estiver fazendo uma aplicação web, por exemplo, a suposta diferença entre o carregamento de uma variável static e outra não-static é simplesmente imperceptível para o usuário. Ou seja: faça sempre um bom design e não se preocupe com otimização, a menos que essa questão realmente apareça.

De nada, por favor, se encontrarem mais sobre o assunto postem aqui junto com os links!

Eu me interesso bastante nessa área de otimização, já li o livro "Java Platform Performance: Strategies and Tactics" e foi interessante. (tem disponibilizado em http://java.sun.com/docs/books/performance/)

Lá também explica como funciona o Java HotSpot, vale a pena dar uma olhada.
http://java.sun.com/docs/books/performance/1st_edition/html/JPAppHotspot.fm.html#998924

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

davidtiagoconceicao wrote:
What code shapes does the JVM optimize best? Here is a list.
Methods
* Methods are often inlined. This increases the compiler's "horizon" of optimization.
* Static, private, final, and/or "special" invocations are easy to inline.
http://wikis.sun.com/display/HotSpotInternals/PerformanceTechniques

Hola,

Isto ainda nao responde as duvidas, pois vejo no artigo:

It's OK to store them in static final fields, too.
Static final fields can hold non-primitive, non-string constants.
Static, private, final, and/or "special" invocations are easy to inline.

Portanto static sao muito mais rapidas... como se prova! Nao existem razoes para nao quererem usar, vejo o contrario indicaçoes recomendando da propria JVM!!

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

Tente usar nomes de variaveis de uma letra so, fica mais rapido tb!

Agora serio, se vc quer evitar o custo de criacao do objeto seria mais inteligente fazer um cache do mesmo.

This message was edited 1 time. Last update was at 12/01/2009 10:35:18

Como se faz cache do objeto? hehe

Hola joaosiqueira

Minha opinião sobre o tema:

1) Alta performance e baixo uso de memória em sistemas OO sempre foi uma questão difícil de resolver vamos dizer assim.

2) O uso mínimo ou nenhum uso de statics é uma caracteristica de bons designs.

Indo mais direto ao ponto: O código sendo estatico ou não ele tem que estar em um trecho da memória da máquina, como o sistema operacional + JVM não são bobos eles mantem estes trechos de código registrado na memória o máximo possível (provavemente seguindo alguma regra baseado no uso). Se tanto o código estatico e o não estático se encontram na mesma condição, vamos dizer assim, resta uma coisa que vou chamar de "code pointer" que aponta para o local da memória onde está o início do trecho de código que será processado; para este mecanismo não importa se o código é estatico ou não o processador verifica o endereço, desloca, processa e pronto.

Resumindo: A questão de ser static está mais associado com estrategia do que com performance, alguns programadores utilizam static ao definir constantes; pois se é uma constante eles não encontram muito sentido deixar o valor ser criado em todas as instancias da classe.

flws.

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

joaosiqueira wrote:

davidtiagoconceicao wrote:
What code shapes does the JVM optimize best? Here is a list.
Methods
* Methods are often inlined. This increases the compiler's "horizon" of optimization.
* Static, private, final, and/or "special" invocations are easy to inline.
http://wikis.sun.com/display/HotSpotInternals/PerformanceTechniques

Hola,

Isto ainda nao responde as duvidas, pois vejo no artigo:

It's OK to store them in static final fields, too.
Static final fields can hold non-primitive, non-string constants.
Static, private, final, and/or "special" invocations are easy to inline.

Portanto static sao muito mais rapidas... como se prova! Nao existem razoes para nao quererem usar, vejo o contrario indicaçoes recomendando da propria JVM!!

Este trecho cita também métodos private e final. E não prova nada, só diz que é mais fácil de otimizar. No máximo, será mais rápido para compilar - não é possível se basear nisso em tempo de execução.

No mais, acredito que procurar "otimizações" para uso do static seja apenas querer argumentar a favor de um design mal projetado: nada contra o uso dele, mas existem casos e casos.

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

Este trecho cita também métodos private e final. E não prova nada, só diz que é mais fácil de otimizar. No máximo, será mais rápido para compilar - não é possível se basear nisso em tempo de execução.

No mais, acredito que procurar "otimizações" para uso do static seja apenas querer argumentar a favor de um design mal projetado: nada contra o uso dele, mas existem casos e casos.

Se vc pensar que todas variaveis membro declarados como static ficam carregas ate vc derrubar a VM, indica q existe um tipo de "cache estatico" na memoria, nao e?

Por isso, partindo desta ideia teriamos uma acelaraçao para os metodos static.
Nao estou considerando design e melhores praticas de refatoraçao.

Pensemos somente em velocidade de execuçao para um código!!

abrs

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

joaosiqueira wrote:
Se vc pensar que todas variaveis membro declarados como static ficam carregas ate vc derrubar a VM, indica q existe um tipo de "cache estatico" na memoria, nao e?

Por isso, partindo desta ideia teriamos uma acelaraçao para os metodos static.
Nao estou considerando design e melhores praticas de refatoraçao.

Pensemos somente em velocidade de execuçao para um código!!

abrs

Mas se você criar um objeto e passar ele pelo seu programa, ele também fica em memória... No final, todo o 'custo adicional' seria relacionado à criação do objeto.

E não entendi como você chegou a conclusão de que um método static pode ser mais rápido se as variáveis static ficam em cache...

Uma dúvida:
Se for criado X>1 objetos do tipo T,
cada objeto T com um método M (não estático),
serão criados X códigos para os métodos dps X objetos? Ou será criado apenas um código na memória e compartilhado entre os objetos?
(por favor, respondam com certeza)

This message was edited 5 times. Last update was at 12/01/2009 12:36:02

Olha, na maioria das JVMs comerciais (todas, eu acho), cada objeto corresponde a uma área de memória. No offset 0 está a referência ao objeto Class correspondente (aquilo que é retornado pelo Object.getClass()), e os demais espaços da área de memória do objeto contém os atributos, um após o outro.

Existem quatro tipos de bytecodes de chamada de métodos: invokestatic, invokevirtual, invokeinterface e invokespecial. Há propostas para que no java 7 apareça o invokedynamic.

De uma forma simples*, podemos dizer que o invokestatic recebe como parâmetro um ponteiro para um objeto Class, um ID de um método estático e um monte de tipos primitivos e ponteiros de Objects que são os parâmetros. Então a JVM vai lá no objeto Class, procura o método ESTÁTICO correspondente ao ID e o invoca passando-lhe os parâmetros.

O invokevirtual e o invokeinterface recebem como parâmetro um ponteiro de um objeto que é a instância em que o método é invocado, um ID de um método não-estático e os parâmetros. A JVM verifica se o ponteiro da instância é nula e lança NullPointerException se for. Se não for, ela vai lá no endereço apontado pelo ponteiro da instância (que é onde está o objeto) e pega a classe deste (que está no offset 0, ou seja exatamente para onde o ponteiro aponta). Tendo então a classe, ela procura o método NÃO-ESTÁTICO correspondente ao ID e o invoca passando-lhe os parâmetros.

O invokespecial é para a chamada de construtores e se não me engano chamada de métodos sobrescritos da superclasse (não sei bem direito como isso funciona no nível dos bytecodes, mas isso não é relevante aqui neste tópico). O invokedynamic vamos deixar para quando sair o java 7.

Então, a estrutura do objeto não contém referências aos métodos. O objeto tem apenas um ponteiro para o objeto Class correspondente e os atributos um após o outro. A JVM usa o ponteiro para o objeto Class para localizar os métodos. Desta forma, objetos de uma mesma classe, ao apontar para o mesmo objeto Class usarão os mesmos métodos que estão no mesmo endereço de memória. Portanto, não há diferenças no uso da memória ou no desempenho** ao deixar um método como estático ou não-estático.

* - Simples, bem simples, para leigos entenderem.
** - Nunca vi nenhum benchmark de quanto tempo a JVM demora para empilhar os parâmetros para a chamada do método (incluindo o ID do método e a referência da instância do invokevirtual/invokeinterface), e nem quanto tempo ela demora para verificar se a referência da instância é nula ou não. 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).

EDITs: Correções de pequenos erros.

Boa explanação victorwss!

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

Completando o que o Victor disse.

Teoricamente, uma chamada "virtual" é um pouquinho* mais lenta que uma chamada não-virtual (e é por isso que o default do C# e do C++ - as chamadas são só "virtual" se forem explicitamente especificadas - é diferente do default do Java). Isso porque em vez de chamar o método diretamente, sem prestar atenção à classe do objeto, o Java deveria chamar o método indiretamente, por um ponteiro contido na definição da classe. Procure por "VTBL" na Internet.

Entretanto,
A JVM compensa esse fato de a chamada ser mais lenta efetuando uma pré-análise da chamada. Se for determinado em tempo de compilação just-in-time que a chamada não precisa ser "virtual" (ou seja, a variável contém um objeto de um determinado tipo apenas, em vez de ficar trocando de tipos que têm em comum apenas a mesma superclasse ou superinterface), então a JVM não faz a chamada virtual e sim a chamada direta (é como se ela determinasse que uma "invokevirtual" na verdade pudesse ser tão rápida quanto uma "invokespecial").
Então não é necessário ficar especificando ou não "virtual" em Java, como é feito no C# ou no C++. Se vocês já programaram em alguma dessas linguagens, viram que na prática vocês acabam tendo de especificar sempre "virtual" para os métodos, para evitar alguns problemas esquisitos. Ou seja: veja o que o Java simplifica para vocês.

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

Por favor, me expliquem a diferença na memoria neste codigo static.
NAO adianta dizer q de uma forma eu crio uma instancia e na outra nao com o uso do new, pois penso q no final tudo se cria uma instancia internamente na VM. Pelo que li nos post acima, o desempenho seria igual nos 2, mas o q difere um do outro?

Como o valor atribuido a um atributo static de uma clase pode manter um valor na memoria ate que a VM seja descarregada, onde esse valor e guardado pra que todas as classes possam ler o valor armazenado e compartilhado?

abrs

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

Por favor, me expliquem a diferença na memoria neste codigo static.
NAO adianta dizer q de uma forma eu crio uma instancia e na outra nao com o uso do new, pois penso q no final tudo se cria uma instancia internamente na VM. Pelo que li nos post acima, o desempenho seria igual nos 2, mas o q difere um do outro?

A chamada a um método estático de uma classe não envolve instanciar essa classe, apenas carregá-la. Portanto o que você disse está errado. Uma forma de você saber isso é criar um construtor e ver quantas vezes esse construtor é chamado: ele será chamado apenas 1 vez.

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