Performance do JAVAW emulando o .jar

3 respostas
dmandrak

Pessoal, eu criei uma aplicação com uma GUI e um botão que ao ser apertado cria um outro Thread com loop infinito.
No total o programinha não passa de 9k.
O fato é, se eu parto ele do eclipse ele funciona legal e talz, até parte rápido. Se eu uso o .jar que eu criei (criado direitinho, não se preocupem, todas as classes dentro) ele demora bem mais pra partir e ainda assim o javaw (no taskmanager) consome belos 30% do processador.
É normal o javaw ser pesado assim? Porque mesmo sem iniciar o loop ele já pesa.
Queria saber se tem maneiras de se aprimorar o .jar pra ele rodar mais leve, no sentido de performance, porque só 9k já é leve o suficiente no tamanho :wink:

Antes de criar esse tópico eu pesquisei aqui no guj e achei esse aqui:

http://www.guj.com.br/posts/list/20818.java#111466

Mas é sobre um problema misterioso de nomes no .jar

Abraços aew.
ps: Lembrando só que é uma discussão de como melhorar a performance, não estou tendo problemas, ok? Está tudo funcionando bem. Caso desejem eu ponho o código aqui, mas acho que não vale muito a pena, só vai sujar a tela :stuck_out_tongue:

3 Respostas

R

Porque mesmo sem iniciar o loop ele já pesa.
Queria saber se tem maneiras de se aprimorar o .jar pra ele rodar mais leve, no sentido de performance, porque só 9k já é leve o suficiente no tamanho

Estou suponde que vc está utilizando o Swing.
Apesar de ser um jar de 9k, a JVM tem que ser carregada com toda as bibliotecas de GUI, e isso é pesado mesmo.

dmandrak

Isso ae, é Swing…
Então é por isso que ele demora.
Hmmm…
Nada resolve isso né?
Tem como mandar ele nao carregar tudo? Porque se não me engano os meus imports eram bem específicos…
A JVM não considera apenas eles né? Ela carrega tudo e depois só puxa pro projeto os que eu pedi :? …
Então acho que não tem saída.

R

Dá uma olhada nessa piração:

http://swingwt.sourceforge.net/

SwingWT offers many benefits:

* [b]More responsive GUIs and faster startup times[/b]
* Less RAM usage for applications
* Many developers prefer the Swing API
* Existing Swing applications don't need to be recoded
* Mature Swing UI designers can be used
* Developers deploying to *nix/Win32 can compile natively with GCJ and the applications can be distributed without a VM. Linux distribution makers could package many existing Java/Swing applications that previously could not be distributed in workable state.
* SWT components can be directly accessed through the API, allowing mix and match (make Eclipse plugins with Swing!)
* All platform benefits such as font sub-pixel decimation for LCD monitors (unavailable in Swing)
* Use Swing on mobile devices!
* The best of both worlds! New Swing components for JClosableTabbedPane, JCoolBar, JTaskTrayItem..
* A FREE implementation of Swing you can redistribute and modify to suit your own requirements
* Insulation from changes to the SWT APIs
* Insulation from differences between SWT platforms
Criado 8 de julho de 2008
Ultima resposta 8 de jul. de 2008
Respostas 3
Participantes 2