"Java não tem performace"

[quote=Andre Brito]Felagund, 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.[/quote]

Existiam diversos problemas justamente com o EntityManager, existia pouco reaproveitamento, então ele era lento por ser mal implementado :P. No final foi ajustado e reescrito, digamos que era um cobaia para testes, no final ele ficou razoavel, e os outros feitos com base nele ficaram muito melhor.

Humm… Perguntei isso porque cometi o erro de criar um EMFactory toda vez que ia usar o EntityManager. Cada operação demorava uns 3 segundos… Aí que fui ler que a criação da Factory é muito cara e deve ser bem limitada no código. Tudo isso pode ser ‘poupado’ de ser feito ao usar DI com @PersistenceContext quando usamos CMP (que já vem no JBoss, por exemplo).

[quote=victorwss]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.[/quote]
Pois é… o maior problema de programas em Java (e em qualquer outra linguagem) são desenvolvedores mal informados (ou as vezes mal preparados) que fazem aquela POG e depois reclamam da linguagem.

[quote=victorwss]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.
[/quote]
(Que venha o java 7!)++

[quote=r4it0.light]Alguém aqui vai desenvolver sistemas de tempo real se sim então JAVA é lento.

Vá estuda C mas C puro onde entra orientação a objeto já começa a fica lento.

Boa sorte com os controles de estoque em tempo real :smiley: [/quote]

Vale lembrar que JVMs tipo JRockit (Oracle) servem pra isso.

[]´s

[quote=lauronolasco]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???[/quote]

Eu já. Trabalhei por 6 anos com sistemas de tempo real, com Java. E em muitos casos era mais fácil obter a performance nele do que no C++.

Entretanto, tenho que concordar à respeito da API de serial/paralela. Não deve ser culpa do Java, mas da implementação da javax.comm. Não é à toa que ela foi descontinuada para o Windows.

Que Java é mais lento que C/C++ todo mundo sabe… mas sempre vai aparecer gente falando o contrário…

Também como é que uma linguagem que gerencia memória através de um GC vai querer comparar com outra que não usa… e ainda por cima precisa de uma VM para interpretar os bytecodes…

Aí é sacanagem né…

Mas em compensação Java é bem mais produtivo que C/C++… vai ver as classes de String em C/C++… ou vai ver as funções de data de C/C++… ou manipulação de arquivos… threads… Web então nem se fala… imagine fazer alguma coisa com CGI… tenho até pena de quem fez isso… Java tem no máximo 10 frameworks conhecidos para cada problema… em C/C++ existem 1 framework para cada empresa… tem vezes(muitas) que existe até 1 framework por programador da empresa…

Fora que um ponteiro errado faz sua aplicação dar crash ou até mesmo invadir outra parte de sua aplicação… em Java isso nunca iria acontecer… o problema mais próximo do Java seria o famoso null pointer exception… mas mesmo assim centenas de vezes menos grave do que um ponteiro mal configurado…

Mas sempre tem aqueles que vão falar… ah, mas se você usar JNI e usar as classes NIO…

[quote=Felipe Kan]Que Java é mais lento que C/C++ todo mundo sabe… mas sempre vai aparecer gente falando o contrário…

Também como é que uma linguagem que gerencia memória através de um GC vai querer comparar com outra que não usa… e ainda por cima precisa de uma VM para interpretar os bytecodes…
[/quote]

Pelo visto você está por fora de alguns anos de evolução da VM e do Java. A VM não interpreta byte-codes. Ela compila. Mas não compila todo o bytecode, e sim, somente os trechos mais usados o que é chamado de Hotspot Compilation.

A Hotspot compilation tem algumas vantagens sobre a compilação feita no C++. Em primeiro lugar, ela pode identificar sobre qual hardware ela está compilando, e ativar otimizações específicas. Em segundo, ela conta com informações de runtime e pode, por exemplo, eliminar sincronização quando percebe que apenas uma thread está rodando, ou fazer inlining de métodos abstratos, coisa que o C++ não faz.

Quanto a gerência de memória, a do Java é centenas de vezes mais eficiente do que o new e delete do C++. Primeiro, porque a VM aloca grandes blocos de memória. Depois, porque ela trabalha com gerações de objetos, não desalocando memória que será rapidamente realocada. Uma experiencia interessante é colocar um código com muitos new e delete num loop, e fazer o mesmo em java. Você vai ver que no Java a performance é centenas de vezes superior. Por outro lado, o Java consome mais memória, já que não tem a filosofia de “você só paga pelo que usar”, que o C++ tem. A desalocação do garbage collection também ocorre em blocos grandes de memória, e alocar e desalocar memória é uma das tarefas mais custosas da maior parte dos sistemas.

Então, é difícil afirmar pura e simplesmente que o java é “mais lento” que o C++. Se você fizer algum programa envolvendo um calculo puramente matemático, é bem provável que na maior parte das vezes o Java realmente seja. Afinal, nele ocorrem poucas alocações de memória, e você provavelmente compilará os dois programas no seu computador, com as otimizações específicas ligadas.

Agora, num contexto mais amplo, duvido muito. Sem falar que o Java tem ferramentas de profiling maravilhosas, como o Visual VM, que permitem que você identifique e corrija os gargalos certos na sua aplicação. Enquanto para o C++ sobra o que? O Valgrind, que só roda em Linux?

Ok, não estou afirmando também que o Java seja mais rápido que o C++ sempre. Não é tão simples assim, porque performance muda de programa para programa. O que quero dizer é que, a menos que você programe firmware, os gargalos dificilmente estarão na linguagem. Aliás, acho muitissíssimo improvável hoje que eles sequer cheguem perto de estar, não é à toa que temos aplicações eficientes rodando em linguagens notoriamente lentas, como PHP.

[quote=r4it0.light]Alguém aqui vai desenvolver sistemas de tempo real se sim então JAVA é lento.

Vá estuda C mas C puro onde entra orientação a objeto já começa a fica lento.

Boa sorte com os controles de estoque em tempo real :smiley: [/quote]

Há uma especificação de Java específica para RealTime, acho que vale à pena dar uma olhada - http://java.sun.com/javase/technologies/realtime/index.jsp

Hoje a solução de 60% das corretoras de WallStreet para operar em tempo real ordens de compra, com latência inferior à 2ms e algorítimos pesados de Trading é o Apama - Progress, engine baseada em Complex Events e escrito em Java.

Neste post do InfoQ vai achar algumas menções sobre o Esper e o BEA Event Server - http://www.infoq.com/news/2007/06/bea-realtime2-eventserver . Esse utiliza a JRockt uma VM com qualidade superior à da Sun para tempo real, aliás, dizem que essa agora com a aquisição da SUN será a versão paga.

Por fim, Java em tempo Real não somente é viável como existe todo um ecossistema de frameworks e soluções. 8)

Agora um sistema de estoque não precisa dessa precisão de 2ms. Você deve estar fazendo algo errado. Vamos lembrar:

O Ebay processa 5 bilhões de chamadas por mês, isso integrando chamadas nativas, soap, entre outras - http://highscalability.com/ebay-architecture

O Twitter, escrito hoje em Scala, roda em cima da JVM.

Diversas empresas de Telefonia, usam sistema de billing escrito em Java (são pesadíssimos), sistemas de home banking e por aí vai.

A Oracle possui o FusionMiddleware que serve de arquitetura para muitas companhias, baseado em Java, assim como a IBM com a linha Websphere e a SAP com o NetWeaver

Hoje, com excessão ao BizzTalk da Microsoft, todos os ESBs de mercado são escritos em Java e lidam com patterns de integração, SLA, tradução de protocolo e precisam escalar em milhares de transações por segundo : http://www.google.com.br/search?sourceid=chrome&ie=UTF-8&q=esb+oracle+performance

Java enquanto plataforma, pra mim em questões ServerSide é imbatível. Acredito muito no futuro de linguagens em cima da plataforma como Scala para desenvolvimento de infraestrutura e Ruby para design de produtos.

[quote=Felipe Kan]Que Java é mais lento que C/C++ todo mundo sabe… mas sempre vai aparecer gente falando o contrário…

Também como é que uma linguagem que gerencia memória através de um GC vai querer comparar com outra que não usa… e ainda por cima precisa de uma VM para interpretar os bytecodes…

Aí é sacanagem né… [/quote]

Acredite que a maioria dos programadores C++ fariam um código de gerencia de memória pior do que está disponível no GC do Java.

Imagine a seguinte aplicação: 7000 usuário simultâneos, média de 25 transações por segundo (picos de 60 transações por segundo), banco de dados… Construir isso não seria simples (C++), deveria ter um servidor para reutilizar conexões, Cache, conexão entre o desktop e o server, controle de transações, etc.

Fica a seguinte pergunta: Em duas equipes, uma C++ e outra em Java, quem faria o software com a melhor performance?

Se a equipe de C++ souber o que esta fazendo, o software deles tera mais performance. Se a equipe de Java souber o que esta fazendo, o software deles tera mais performance.
A menos que você esteja fazendo algo que cada milisegundo de uma única operação é relevante (controle de um reator numa usina nuclear) ou uma aplicação 100% desktop, eu não acho que teria tanta diferença assim.

Eu acho que é um pouco questão de produtividade, eu li a algum tempo que se queremos um projecto pequeno de 1 mês e com um programador por exemplo , não se pensa 2 vezes e é bom avançar com php ou asp ou outra linguagem de rapido desenvolvivento.

E tambem entendi que se quisermos trabalhar num projecto numa equipa grande e se tivermos alguns meses para acabar com o projecto e se o projecto for algo que é bom que seja de facil manutenção e reusabilidade do código , sem sombra de duvidas é java na certa.

Pode ser que esteja errado, mas eu encaro assim a idea

Bom, primeiro de tudo, é necessário dizer o que é um sistema de “tempo real”. Um sistema de tempo real é um sistema que, para determinados processamentos, existe um intervalo de tempo máximo que esse possa ser realizado. Note que isso não implica em um sistema em que tudo deva ser realizado em poucos milisegundos, pois um sistema de tempo real pode, até mesmo, ter esse tempo estipulado em minutos.

O sistema é dito de “soft real time”, se esse intervalo pode ser ferido ocasionalmente, o que gerará uma perda controlada.
O sistema é dito de “hard real time” se ao ferir esse intervalo, a perda inviabiliza o uso do sistema.

O problema do Java no real time é que ele não permite que você faça uma aplicação determinística, por mais esmero que você tenha. Afinal, o garbage collector não estará sobre seu controle, e a aplicação vai literalmente pausar quando ele roda. Portanto, é importante analisar a duração média dessas pausas no seu sistema, e ver se elas ferem o intervalo de tempo estipulado, ou se elas são toleráveis como “perdas controladas”, no caso do soft real time.

Quer saber a verdade? A PURA verdade?

Então vai (não joguem pedras): em 99% dos casos que já vi semelhantes a estes quem criticava Java era justamente o povo do “arrastar e soltar”.
Gente que só sabia programar com a parte visual do Delphi, VB6 ou Visual Studio e que, ao topar com Java, por não ter base alguma, dava com os burros n’água.
Simples assim.

Ai a tecnologia é ruim, não funciona direito, etc…
Sempre o MESMO papinho furado.

É o pessoal que, costumo dizer, vive na caverna (já escrevi sobre isto aqui: http://www.itexto.net/devkico/?p=273 )

ps:
não, não estou dizendo que Delphi, VB6 ou Visual Studio sejam ruins, mas sim que o povinho do “arrasta e solta” cria o inferno pro pessoal ao redor e não sabe (ou pior ainda, sabem!)

Mas o VB6 é mesmo ruim. Muito ruim.

Concordo com kicolobo, infelizmente java não é para qualquer um. Eu não pensava assim…mas a cada dia que passa me aproximo mais desta conclusão.

Outra coisa que já observei e comprovei: quem aponta performance como ponto negativo em Java é porque tem problemas com programação em qualquer linguagem OO na maioria dos casos. A diferença é que linguagens como Delphi acoberta este tipo de coisa, ela causa uma espécie de compensação.

A lentidão na API Swing é uma fato, porem a SUN tem trabalhado no assunto nos últimos tempos (como já foi muito bem explicado antes). Detalhe, a SUN começou a trabalhar nisto por causa de muita insistencia das comunidades. Ou seja, o mercado desktop era dominado pelas linguagens Delphi, VB e outros “gatos pingados” e ela (SUN) nunca teve interesse em “entrar” nesta àrea por saber do real potencial das linguagens alí estabelecidas; concordemos, a Microsoft está no mundo desktop a muito tempo e ela não pode ser tão ruim assim - experiencia é que não falta.

Isto significa dizer que se vc escolheu Java para fazer uma coisa que Delphi / VB / etc… poderiam fazer bem então o erro foi seu; não soube analisar e escolher a ferramenta correta para o problema em questão.

Só escolha a plataforma Java se vc concluir que o problema será melhor resolvido com ela, caso contrario resultará em discusões sem sentido.

Mais uma coisa, tem profissional que acha que fazer POGs “na moita” na plataforma Java vai ficar por isso mesmo; não fica de jeito nenhum. Mais cedo ou mais tarde o problema aparece e normalmente é em forma de baixa perfomance.

flws

[quote=kicolobo]Quer saber a verdade? A PURA verdade?

Então vai (não joguem pedras): em 99% dos casos que já vi semelhantes a estes quem criticava Java era justamente o povo do “arrastar e soltar”.
Gente que só sabia programar com a parte visual do Delphi, VB6 ou Visual Studio e que, ao topar com Java, por não ter base alguma, dava com os burros n’água.
Simples assim.

Ai a tecnologia é ruim, não funciona direito, etc…
Sempre o MESMO papinho furado.

É o pessoal que, costumo dizer, vive na caverna (já escrevi sobre isto aqui: http://www.itexto.net/devkico/?p=273 )

ps:
não, não estou dizendo que Delphi, VB6 ou Visual Studio sejam ruins, mas sim que o povinho do “arrasta e solta” cria o inferno pro pessoal ao redor e não sabe (ou pior ainda, sabem!) [/quote]

Adorei!

Esses dias tava acompanhando uma discução na lista de flex e o pessoal tava reclamando do eclipse.
Estavam dizendo que sem a ferramenta dnd o eclipse se torna um “notepad pesado”.
Ou seja, tirou o arrasta e solta a galera já não sabe mais programar… se é que sabia antes.
E a culpa é da IDE, lógico, afinal onde já se viu uma IDE sem dnd, absurdo!!

Uma coisa que o Java é realmente ruim é na integração com SO ou com hardware externo. Se você precisa disso, pense bem se o resto da API do Java vai compensar essa desvantagem. Escrever JNI é difícil, sujeito a erros, perigoso, e é C++, não Java.

[quote=Rubem Azenha][quote=evandro.santos]
Acredite que a maioria dos programadores C++ fariam um código de gerencia de memória pior do que está disponível no GC do Java.

Imagine a seguinte aplicação: 7000 usuário simultâneos, média de 25 transações por segundo (picos de 60 transações por segundo), banco de dados… Construir isso não seria simples (C++), deveria ter um servidor para reutilizar conexões, Cache, conexão entre o desktop e o server, controle de transações, etc.

Fica a seguinte pergunta: Em duas equipes, uma C++ e outra em Java, quem faria o software com a melhor performance?
[/quote]

Se a equipe de C++ souber o que esta fazendo, o software deles tera mais performance. Se a equipe de Java souber o que esta fazendo, o software deles tera mais performance.
A menos que você esteja fazendo algo que cada milisegundo de uma única operação é relevante (controle de um reator numa usina nuclear) ou uma aplicação 100% desktop, eu não acho que teria tanta diferença assim.[/quote]

Mesmo uma equipe que saiba muito o que está fazendo (que por sinal seria muito mais cara do que a equipe de Java) C++ tem o problema de não possuir uma grande variedades de frameworks e APIs disponíveis (a um preço que não comprometa o projeto), imagine o tempo de implementar: classes para fazer Cache, Pool de conexões, controle de transação, um protocolo de comunicação (sockets é dureza), etc. Implementar isso tudo exige muito conhecimento e um bom tempo.

Você pode usar qualquer linguagem que gere codigo nativo para criar uma JNI…

Nao precisa ser C++

Se quiser pode até utilizar o delphi (Já fiz isso varias vezes)…

:slight_smile:

JNI is Easy e normalmente constitui 2% a 10% no maximo do seu software…

Não justifica trocar 90% por 10%… escreve 90% em java e 10% em delphi via dll … pronto… melhor dos dois mundos :slight_smile:

[quote=evandro.santos]
Mesmo uma equipe que saiba muito o que está fazendo (que por sinal seria muito mais cara do que a equipe de Java) C++ tem o problema de não possuir uma grande variedades de frameworks e APIs disponíveis (a um preço que não comprometa o projeto), imagine o tempo de implementar: classes para fazer Cache, Pool de conexões, controle de transação, um protocolo de comunicação (sockets é dureza), etc. Implementar isso tudo exige muito conhecimento e um bom tempo.[/quote]
Hum… o problema principal em aplicações C++ não é a variedade de frameworks (ok, eu sei que um monte deles tem de ser adquirido em vez de ser open-source). O problema principal, a meu ver, é que é difícil detectar certos erros primários que costumam causar apenas stack traces em Java, mas provocam falhas fatais em C++. Isso atrasa sobremaneira o desenvolvimento.