Guerr@…
novamente repito…
não estou colocando a culpa no java…
tanto é que consegui resolver o problema com o proprio java…
vcs ja trabalharam com ADC???
[quote=Guerr@]Acho que a grande questão é avaliar o que estava causando a perda de desempenho.
Rede, acesso ao BD, algoritmos mal implementados, criação de objetos desnecessários… Se for feita uma avaliação é bem provável que o problema esteja fora da JVM.
Porém as vezes é mais fácil colocar a culpa no que não está sobre o nosso controle.[/quote]
Interessante…
[quote=moacirjava][quote=Guerr@]Acho que a grande questão é avaliar o que estava causando a perda de desempenho.
Rede, acesso ao BD, algoritmos mal implementados, criação de objetos desnecessários… Se for feita uma avaliação é bem provável que o problema esteja fora da JVM.
Porém as vezes é mais fácil colocar a culpa no que não está sobre o nosso controle.[/quote]
Interessante…[/quote]
Acredite vc pode usar JAVA ou C# em qualquer lugar ocupado por VB e o Delphi.
Claro se você vai escrever um software que auxilie uma cirurgia remota por exemplo esse sim é um lugar que JAVA não poderia ocupar, na verdade nem VB nem Delphi.
Embora eu imagino que no futuro nós poderemos escrever esse tipo software usando maquinas virtuais.
[quote=lauronolasco]Guerr@…
novamente repito…
não estou colocando a culpa no java…
tanto é que consegui resolver o problema com o proprio java…
vcs ja trabalharam com ADC???[/quote]
Nimguem analisou seu codigo, afinal vc não o postou… mas o seu relato aponta para uma resposta simples…
THREAD
Oi! É assim, o JIT grosseiramente falando a primeira vez roda mais lento, mas se a rotina for executada uma segunda vez, ela seria executada compilada, daí ganha performance.
Isso acontece quando você chama um método do Java mais de uma vez, ou quando o sistema entra em um loop. No caso que você colocou o link, o fibonnaci é um exemplo onde a compilação JIT funciona bem porque ele é praticamente repetição. Mas em um programa grande do “mundo real”, você vai ter códigos que podem ser repetidos e códigos sequenciais, então o aproveitamento vai ficar “numa média”.
O Delphi roda tudo nativo, daí é natural que seja mais rápido. Mas, como os colegas disseram, é pesar os prós e contras.
[quote=marcosalex][quote=r4it0.light]
Então qual o teste que você sugere para performance ?
[/quote]
Oi! É assim, o JIT grosseiramente falando a primeira vez roda mais lento, mas se a rotina for executada uma segunda vez, ela seria executada compilada, daí ganha performance.
Isso acontece quando você chama um método do Java mais de uma vez, ou quando o sistema entra em um loop. No caso que você colocou o link, o fibonnaci é um exemplo onde a compilação JIT funciona bem porque ele é praticamente repetição. Mas em um programa grande do “mundo real”, você vai ter códigos que podem ser repetidos e códigos sequenciais, então o aproveitamento vai ficar “numa média”.
O Delphi roda tudo nativo, daí é natural que seja mais rápido. Mas, como os colegas disseram, é pesar os prós e contras.
[/quote]
Na verdade marcos não fui eu quem postou o link com FIBONACCI.
Ops :oops:
Gosto do Delphi, acredito que pra programação desktop é a IDE mais produtiva de todas e desde 2005 eles aderiram aos padrões de projeto e incentivam o pessoal a separar a regra de negócios da interface, um vício que os programadores antigos tomavam, de colocar a lógica no botão.
É natural você gostar de uma ferramenta onde criou habilidades.
Java em desktop realmente é bem lento, isso em todos os programas em java desktop q conheço, só o start do programa é leeeeento.
Eu já fiz programas desktop em java e comparado com .net, nossa.
Creio que Swing seja uma API pesada, não lenta. Por ser pesada, geralmente é lenta no startup (pois carregar a API leva tempo), mas não durante a execução. E aqui estamos falando especificamente de Swing. Java é muito mais que isso, mesmo para aplicações desktop.
“Java não tem performance” é a típica frase de alguém que nunca fez um programa de verdade em Java e viu algum programa mal feito dando problemas desenvolvido por alguém que encheu de POGs o programa e colocou a culpa no Java.
[quote=r4it0.light]Outra coisa que vale lembrar que o unico rival para o Java hj é o C#, que por sinal tem um framework para jogos sensacional o famoso XNA.
[/quote]
Já ouvi falar no XNA, mas nunca me aprofundei (até porque sou Linux User). O que ele tem demais? Outro dia vi um artigo sobre como criar um jogo 2D com XNA. A única diferença notável para o Java nesse código é que ele tem dois métodos herdados, um para carregar imagens (ImageIO.read em Java) e outro para ler o estado do teclado (KeyListener, em Java). Até então nada demais. Sem contar desvantagens como estar preso à tecnologia proprietária exclusiva da MS.
Já vi alguns screenshots para jogos 3D, mas creio que Java esteja ao mesmo nível para a maioria das coisas que se pode fazer (exceto para funções muito específicas, como do DirectX, por exemplo). Só como exemplo, vide jmonkeyengine.
Foi isso que um colega de classe falou para mim.
“… Você sabe que java é lento , vou estudar Delphi, isso com 2 anos++ de exp com Desktop…” Ele deve ter os motivos dele mais como um amigo falou no inicio do tópico nada me faz mudar para delphi.
[quote=Hellmanss][quote=lauronolasco]Guerr@…
novamente repito…
não estou colocando a culpa no java…
tanto é que consegui resolver o problema com o proprio java…
vcs ja trabalharam com ADC???[/quote]
Nimguem analisou seu codigo, afinal vc não o postou… mas o seu relato aponta para uma resposta simples…
THREAD[/quote]
como eu falei num dos posts… usei thread e o problema foi amenizado, porém não me deu um retorno satisfatório para o meu caso.
como o r4it0.light disse:
O AWT foi criado com alguns erros de projeto graves. O Swing foi criado por cima do AWT com a intenção de substituí-lo (o que por si só já é um erro, pois se é para substituir, que não fizessem por cima). No entanto o Swing também contém os seus próprios erros de projeto.
O Swing é uma API pesada, em parte porque ele é projetado na forma de classes gigantescas, o que faz com que suas instâncias sejam gigantescas na memória. Excesso de consumo de memória trás problemas de desempenho quando ocorre swapping na memória cache ou pior ainda, swapping na memória virtual. O desempenho vai para o saco. Outro problema é que o próprio programa fica maior.
Além disso, pouca gente sabe, mas o AWT (e o swing vai junto) tem uma Thread de eventos dedicada a responder a interface gráfica e renderizar a tela, chamada Event Dispatch Thread (EDT). Quando esta thread acaba entrando em tarefas que abrem arquivos, fazem conexões de rede, esperam em blocos synchronized, fazem consultas no banco de dados ou fazem algum processamento pesado, a interface do usuário para de responder e o programa começa a engasgar. A solução para isso é simples: NUNCA FAÇA TAIS TAREFAS NA EDT. O problema é que grande parte dos programadores swing sequer sabe que existe essa EDT ou como ela funciona. Além disso, isolar estes códigos para rodarem em outras threads e fazer uma notificação correta entre threads é um trabalho razoavelmente difícil.
Se você não tomar cuidado com a EDT, o seu programa desktop em java VAI ficar extremamente lento e não há nada que você possa fazer exceto colocar as coisas nas threads corretas, algo que chuto que nem 5% dos programadores swing devem saber como fazer. Talvez nem 2%.
Como se isso não bastasse, as próprias tarefas que a EDT deve fazer podem ser lentas, tais como renderizar a tela ou fazer o layout corretamente. Tirar o máximo de desempenho dessas coisas é algo árduo e complexo. Mas felizmente, pouca gente precisa se dar ao trabalho de fazer isso, pois a maioria dos componentes já prontos são eficientes o bastante e dificilmente você pega um caso aonde não seja.
Mas, a pior parte é o coletor de lixo, que é uma das maiores pragas na questão de desempenho no java. Pode ocorrer que o coletor de lixo seja escalonado para o processador e outras threads parem, inclusive a EDT. E otimizar o desempenho do coletor de lixo e minimizar a interferência dele no desempenho do resto do sistema é algo bem chato, complicado e trabalhoso.
No entanto, o desempenho do swing vem melhorando cada vez mais. Já vi em algum lugar uma comparação de desempenho (estou com preguiça de procurar no google agora), mas a cada versão do java o desempenho do swing dá um salto gigantesco. No java 1.2 praticamente não era usável. No java 1.4 já era bem melhor, mas ainda era bem pesadão. No java 5 ficou razoavelmente leve. No java 6, ele já bate o delphi e o VB em alguns casos. Com o java 6 update 10 melhorou mais ainda. Que venha o java 7.
Porque Java pra Desktop era ruim. Podem me ignorar ou falar que estou errado, mas antes era lento e não tem nada que me faça pensar o contrário. Me desculpem a grosseria, mas já vi muita gente comentando que não é lento, que é só saber programar direito, mas ainda assim não me convenci.
Hoje é um pouco diferente… Ocorreram algumas alterações no Java 6 Update 10 (se não me engano, e no 7 está para melhorar mais ainda) que melhoraram a performance, então é bem provável que as coisas comecem a melhorar pro lado do Swing. Mas assim… Acho que Delphi é bem produtivo também, as vezes até mais que Java quando se trata de botõezinhos e caixinhas e formulários pra sistemas Desktop.
Sobre o Java 7, não lembro direito onde que li isso, mas ele vai ser quase 50% mais rápido que o Java 6. O Java 6, quando comparado ao 5, foi um pouco menos que 20% mais rápido. Acho que de uns tempos pra cá as coisas podem melhorar pro Java pra Desktop, quando Swing é usado. Eu, particularmente, já vi uma boa melhora na velocidade de aplicações Swing.
Dá uma procurada por Java 7 Performance. Devem ter vários artigos bem interessantes sobre esse tipo de coisa.[/quote]
Oi,
Programa em Java Desktop a algum tempo (5 ou 6 anos…)… Nunca tive problemas com lentidão.
Tchauzi!
[quote=matarra1000]Java em desktop realmente é bem lento, isso em todos os programas em java desktop q conheço, só o start do programa é leeeeento.
Eu já fiz programas desktop em java e comparado com .net, nossa.[/quote]
Oi,
Tenho varios projetos Desktop como: Replicador de base de dados e um super TEF Dedicado. Ambos utilizando Swing, Threads, XML e outros conceitos.
Para ter uma ideia: O Replicador (Utilizando Swing, interface, banco e threads) é capaz de “puxar” um estabelecimento com quase 1mil lojas e sem problemas.
Tchauzin!
nunca tive problemas sérios de performance com o swing, mas testem com o java 6. Recentemente atualizamos os clients para jre 6 up 10 e as aplicações ficaram mais rápidas.
[quote=lauronolasco]Hellmanss…
vc viu o código pra dizer que é “nas coxas”???
vc ja trabalhou com alguma tarefa de precisão em função do tempo com java???
em nenhum momento eu coloquei a culpa no java…
mas é inegável que pra trabalhar com desktop ele é mais lento…
dependendo do seu problema, essa diferença no tempo pode não influenciar o resultado final…
ou pode… como foi o meu caso!!!
[/quote]
Deveriam ter usado então a JVM em “tempo real” que a IBM fez para algum projeto estranho para o exército americano, uma JVM que precisava estar num ambiente em “tempo real”, rodando sobre uma distribuição Linux em “tempo real”. Ou então a própria solução da Sun para Java em “tempo real”.
Inté.
Tivemos em algums projetos algum problema quando o Hibernate conectava com o Banco, e isso causava uma certa lentidão, alguns segundos de espera, mas os novos sistemas que foram feitos, foi usando Swing e uma camada EJB, a aplicação Swing voou, e ficou muito mais rapida que as aplicações feitas em Delphi (O Sistema tinha a versão em Delphi e foi reescrito para Java). Além da interface ficar mais elegante ficou muito rápido.
Antigamente também achava que java para Desktop era lento, hoje em dia penso diferente.
Oops
Correção aplicações em tempo real podem ser escritas em JAVA segue o link
http://java.sun.com/javase/technologies/realtime/index.jsp
Embora nos casos que você queira utilizar tudo que o hardware possa te oferecer nada melhor que o bom e velho CFelagund, por um acaso vocês não criavam um EntityManagerFactory sempre que iam lidar com o banco?
Lina, eu quis dizer na parte de Swing do Java. Pelo menos comigo e com uma fatia bem grandinha de pessoas era lento. Hoje a história é, de fato, bem diferente.