Depois de pesquisar sobre diversos profilers para analisar uma aplicação Java, cheguei na conclusão que o JProfiler é o melhor. O único problema do JProfiler ate agora é que ele é pago.

Vamos instalar uma versão trial dele e ver o que podemos fazer com ele. Para descarregar o trial do JProfiler primeiro temos que acesar essa pagina e preencher o formulário. Um key para poder testar a ferramenta por dez dias será enviado. Seguidamente podemos entrar na área de downloads e baixar a versão desejada. A versão que eu estarei baixando é a 5.1.2, versão instalação executável.

A descarga finalizou e também chegou meu key, agora vou instalar. Vou ir no console na pasta onde descarreguei o arquivo e dar um ./jprofiler_linux_5_1_2.sh. Seguidamente é aberto um wizard onde aceitamos os termos do programa e indicamos onde queremos instala-lo.

Ao abrir o programa pela primeira vez é apresentado outro wizard, dessa vez uma wizard de configuração. Nesse wizard devemos inserir nossa key, escolher a VM que desejamos utilizar, indicar se queremos integrar o JProfiler com algum IDE e escolher nosso browser, é um processo bem simples.

Uma vez terminado o segundo wizard aparece um terceiro onde podemos indicar qual aplicação queremos que o profiler analise. Podemos também configurar para fazer que esse wizard apareça toda vez que abrirmos o programa ou não. Eu escolhi para aparecer toda vez porque é um wizard muito simples e faz que em um tempo muito pequeno tenhamos um profiler trabalhando com nossa aplicação escolhida.

Nessa oportunidade, vou utilizar o profiler com uma aplicação web minha que estou fazendo. A aplicação e muitos simples e possivelmente não vamos poder descobrir picos de garrafa, mas vamos poder obter uma idéia do que podemos fazer com o JProfiler. Justamente pelo que vou analizar uma aplicação web vou escolher no wizard a opção An application server, locally or remotely. Vou dar next e seguidamente vou escolher a versão do servidor de aplicação que vou utilizar, JBoss 4.x no meu caso. Next novamente, escolho que o servidor de aplicação esta nessa máquina e dou next novamente. Agora vou indicar qual é o arquivo que levanta o servidor. No meu caso ele se encontra na pasta /bin/ e se chama run.sh. Passos seguintes são escolher a máquina virtual a utilizar, a porta desejada para a conexão do profiler e decidir se queremos que nosso servidor de aplicação espere por uma conexão do profiler antes de inicializar ou não. Vou escolher a opção Wait for connection from the JProfiler GUI que quer dizer que quero que espere e avançar para o próximo passo. No seguinte passo é visualizado um resumo do que foi configurado e no ultimo temos a opção de escolher se queremos inicializar o servidor agora ou deixar isso para mais tarde. Vou escolher que quero inicializar agora escolhendo a opção Yes, start the application server for profiling.

Uma vez finalizado o wizard apareceu para mim uma janela indicando que minha versão e de evaluação. Tenho a opção de inserir uma key pagar. Vou fazer click em Evaluate para evaluar somente porque não comprei nada.

Antes de iniciar o servidor aparece uma janelha onde podemos fazer umas ultimas configurações. Também é indicado o nivel de CPU e memória que o JProfiler precisara de acordo com o configurado. Eu quero que tudo seja gravado então vou escolher as opções Record CPU data on startup e Record allocations on startup que vão a analizar quando cpu e quanta memória o servidor utiliza para inicializar.

Vou mudar a configuração do meus filtros porque não quero que todas as classes sejam analisadas, somente as classes do pacote com.mouseoverstudio . Na seção Filter settings vou fazer click em Edit. Por default, nos filtros ja vem configura um filtro para excluir do analise um monte de classes. Vou deixar as coisas mas simples apagando esse filtro e incluindo um novo do tipo inclusivo com o valor com.mouseoverstudio .

Seguidamente ok na janela e ok novamente na outra janela.

É aberto uma console com o debug do JBoss onde podemos ver que ele esta inicializando.

Durante a inicialização podemos ir no JProfiler na opção VM Telemetry Views e ver a memoria ram que esta sendo consumida em tempo real e ao longo de tempo de vida do nosso servidor:

Na parte inferior aparecem umas abas. Se fizermos click na aba Recorded Objects podemos visualizar a quantidade de objetos que residem na memória. Nas outras abas podemos analisar a quantidade de objetos criados e liberados da memória (Recorded Throughtput), a atividade do Garbage Collector (GC Activity), a quantidade de classes sendo analisadas pelo profiler (Classes), os Threads (Threads) e a carga do cpu (CPU Load).

Vou navegar um pouco na minha aplicação, vou selecionar uma funcionalidade pesada e durante sua execução vou me dirigir no JProfiler. Na opção Memory Views podemos ver o numero de instâncias existentes na memória, agrupadas por classes, pacotes ou componentes e quanta memória esse número de instâncias estão utilizando. Num primeiro momento é mostrada informação sobre todas as classes do sistema.

Como eu quero ver somente informação sobre minhas classes, vou me dirigir para View Filters e digitar com.mouseoverstudio . Ao dar enter são filtradas as classes que não pertencem ao pacote com.mouseoverstudio .

Essa funcionalidade é muito legal. Nessa semana estava analisando a aplicação de um cliente quando vi que ao acessar uma funcionalidade x, eram criadas muitas instâncias de um objeto o qual não deveria ter mais de uma por usuário. Depois de analisar o código com os desenvolvedores a gente percebeu que estava sendo criada a instância de um classe dentro de um loop, quando deveria ser fora de acordo com a lógica do negocio.

Eu sabia que estavam sendo criadas muitas instâncias de um classe, mas como saber onde eram criadas estas instâncias? Na seção CPU Views podemos visualizar uma árvore de chamadas sendo realizadas na VM. Dentro da informação se encontra o peso de aquela chamada em relação as outras, o tempo que demorou e o numero de invocações que teve. Podemos agrupar as chamadas novamente por métodos, classes, pacotes ou componentes, filtras informação de certo pacote ou de certa thread.

Na aba Hot Spots temos informação parecida, mas partindo de outras fontes, chamadas Hot Spots. Eu estou na dúvida sobre se sei corretamente o que é um Hot Spot e o que representa mas sei que a informação apresentada parte deles.

Se fizermos click direito numa classe dentro da árvore e selecionarmos Show Call Graph vamos poder visualizar a informação desejada mas de um modo gráfico, podendo escolher um layout hierárquico, ortogonal ou orgânico. Nesse gráfico é apresentada a mesma informação e podemos ir navegando por ele e abrindo conexões, podendo apreciar como as classes estão se relacionando entre sim.

Foi assim que no caso do cliente eu escolhi uma classe de partida que eu sabia que a requisição tinha passado por ali e fui navegando ate achar a classe que criava aquela quantidade enorme de instâncias.

JProfiler tem muita outra informação a oferecer, mas como eu sou ainda novato com a ferramenta, não entendo toda ela corretamente e poderia confundir as pessoas se tratasse de explica-las. Porém, com o que eu tenho aprendido e tentado explicar nesse post ja da para fazer muito análise de uma aplicação e tirar uso da ferramenta. Justamente com aquele uso e que se vão aprendendo novas coisas e conforme eu for aprendendo vou ir postando aqui.

Qualquer informação a mais por favor deixar-las nos comentários.

A operação de selecionar todos consistia em fazer um loop das options do select e marcar cada uma como “selected = true”. Tentando optimizar o processo um dos desenvolvedores lembro das épocas em que mexia com VB e sugeriu ocultar o select, fazer o loop e depois mostrar o select de novo. O resultado foi impressionante, o processo foi umas 20x mais rápido!

Segue o script e uma prova do mencionado. A função selectAll1() implementa o procedimento utilizado em primeira instância. Já a função selectAll2() implementa também o hack de ocultar a combo antes de fazer a operação. Nas duas funções e logado o tempo que demorou a operação.

function selectAll1() {
	var date = new Date();
	var options = document.getElementById("select").options;
	var optionsLength = options.length;
	for (var i = 0; i < optionsLength; i++) {
		options[i].selected = true;
	}
	log(1, new Date() - date);
}

function selectAll2() {
	var date = new Date();
	var select = document.getElementById("select");
	select.style.display = "none";
	var options = select.options;
	var optionsLength = options.length;
	for (var i = 0; i < optionsLength; i++) {
		options[i].selected = true;
	}
	select.style.display = "";
	log(2, new Date() - date);
}

function log(i, ms) {
	document.getElementById("console").innerHTML += "selectAll" + i +
			" : " + ms + "ms“;
}

No IE a função selectAll1 demorou em média 700ms, a diferença da função selectAll2 que foi executada em somente 30 segundos na média. No Firefox os resultados das duas funções não foram tão distantes. Demoraram em média 150ms e 140ms respectivamente.

O artigo ja tem dois anos de vida mas mesmo assim foi de muita utilidade. Basicamente o que Riyad recomenda e inicializar o Eclipse com os seguintes argumentos numa máquina com 1GB de memória RAM:

-vmargs -Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m

No caso de possuir outra quantidade de memória RAM, basta com proporcionar os valores diretamente. Por exemplo, se tivermos uma máquina com 512 MB de RAM, os argumentos ficariam assi:

-vmargs -Xms256m -Xmx256m -XX:PermSize=64m -XX:MaxPermSize=64m

Os argumentos são especificados no arquivo eclipse.ini dentro da pasta principal do Eclipse. Nesse casso, os argumentos especificados servem para indicar a VM quanta memória ela pode usar para alocar classes e outros recursos. Ao possuir mas espaço disponível, a performance melhora. Somente não podemos dar a oportunidade dela poder pegar muita memória porque ali outras aplicações poderiam se ver afetadas.

Conhecendo isso podemos combinar a velocidade de destruir elementos tirando o elemento pai ao utilizar os métodos do DOM com criar novos elementos utilizando innerHTML.

Foi assim que uma solução foi sugerida e devido a participação dos leitores nos comentários foi melhorada notavelmente. DrSlump percebeu que mesmo a função sendo bem mais rápida que o innerHTML no Firefox, no IE era mais lenta e recomendou uma compilação condicional. Por sua parte, Dean Edwards sugeriu a utilização do método cloneNode para poder transferir todos os atributos de um elemento pra outro. Ao final a função ficou assim:

function replaceHtml(element, html) {
	var oldElement =
			(typeof element === "string" ? document.getElementById(element): element);
	/*@cc_on // innerHTML puro e mais rápido em IE
		oldElement.innerHTML = html;
		return oldElement;
	@*/
	var newElement = oldElement.cloneNode(false);
	newElement.innerHTML = html;
	oldElement.parentNode.replaceChild(newElement, oldElement);
	/* Como acabamos de remover o elemento antigo do DOM, retornar uma referenca
	ao novo elemento, o qual pode ser utilizado para restaurar referencias da variable */
	return newElement;
};

Para testar os resultados podem acessar a página criada pelo mesmo Steven.