sixhat pirate parts

Viva,

Outra coisa fácil de configurar e que costuma resultar em ganhos na performance é o tamanho inicial e maxímo da heap, para isso basta-​​te configurar –Xms (initial heap size) e –Xmx (maximum heap size). Podemos assim evitar que o GC entre em acção mesmo quando existe memória que poderia ser usada pela JVM.

Poderias também entrar em assuntos como o tunning do GC, mas isso é daquelas “artes mágicas” algo complexas (pelo menos eu acho, mas também não sei assim tanto sobre o assunto) que ou sabemos realmente o que estamos a fazer ou então em vez de melhorarmos pioramos a performance.

Ah já agora, talvez já saibas mas fica aqui a dica, a JVM possui um profiler muito simples que podes usar quando estás a fazer estes testes, o JConsole. Para o usares basta começares a jvm com mais um switch: –Dcom.sun.management.jmxremote. Depois enquanto o programa java estiver a correr, basta lançares o jconsole (que está no $JAVA_​HOME/​bin).

A server-​​vm tem uma melhor performance do que a client-​​vm, mas o consumo de memória (que pode ser muito maior) e o tempo extra de arranque das aplicações pode negar esse ganho. Para aplicações que vão correr durante muito tempo, praticamente sozinhas, numa máquina com memória em grande quantidade, a server-​​vm é claramente melhor.

Para aplicações desktop, se calhar não. Ganhas na performance das aplicações Java, e perdes no resto do sistema. Para o utilizador é capaz de ficar tudo na mesma.

O Carlos tem toda a razão.

Que tal colocares o resultado do:
time java –server aplicacao
time java –client aplicacao

To David: Está visto que não me fiz perceber. Por isso vou tentar outra vez e até incluo código:
public class Primos {

public static void main(String[] args) {

int n = 100000;
boolean primo;
int i,z;
long inicio, fim;
inicio = System.currentTimeMillis();
for (i = 1; i <= n; i++) {
primo = true;

for(z = 2 ; z <= i/​2 && primo; z++ ){

if(i%z == 0)
{
primo=false;
}
}
}
fim = System.currentTimeMillis();
System.out.println(“Demorou ” + (fim-inicio)/(float)1000 + ” segundos de tempo total.”);

}
}

Este código vai indicar o tempo que a JVM esteve efectivamente a trabalhar. Comparar os outputs com –client e –server vai mostrar se existe um aumento de performance.
Ao usar o “time java –client Primos” e “time java –server Primos” vai nos mostrar o overhead no arranque da JVM. Os tempos que tu indicas devem ser apenas os reportados pela aplicação.

O problema destes “benchmarks” sintéticos é que o processamento é demasiado focado para se conseguir tirar conclusões válidas. Os testes correm durante pouquíssimo tempo, não geram grandes alocações de memória, e resumem-​​se a umas quantas linhas de código que, com um pouco de sorte, uma vez JITadas cabem dentro da cache do CPU.

Porque como eu dizia, se tens um Eclipse a consumir quantidades obscenas de memória, e tens um Firefox ao lado com algumas tabs e mais uma coisa ou outra e não tens 4Gb de RAM, se calhar vais começar a usar swap, quando com a client VM cabe tudo na memória e a perda de performance não se nota (porque a aplicação passa a maior parte do tempo à espera de input).