Lendas urbanas: custo de alocação em Java
Segundo este artigo da IBM, estudos mostram que o tempo de alocação de um objeto em Java, utilizando a palavra chave new, é menor que o custo de um malloc em C. Os dados são interessantes: um new requer 10 instruções de máquina, enquanto que um malloc requer entre entre 60 e 100 instruções. Outro dado interessante do artigo é que o uso do Garbage Collector tornaria o processo mais eficiente do que o gerenciamento manual de memória, pelo fato do primeiro tratar de blocos maiores.
Meus comentários a respeito:
- A performance de Java melhorou muito ao longo do tempo. Mas o footprint da JVM, para qualquer programinha, ainda é muito grande. Alocação de objetos em Java pode ser mais rápido do que em C/C++, mas com certeza programas em C/C++ fazem um uso mais racional de memória.
- Esta área de otimização de memória, footprint, execução é a área de aprimoramento que a Sun deveria se concentrar exclusivamente, em vez de ficar inventando moda com closures, Java FX e outras coisas script-like. Java não vai conseguir concorrer com linguagens de script. Java tem que concorrer com C++.
- A minha experiência com alocação de grandes quantidades de dados em Java, aplicada ao processamento de sequências genéticas, não foi das melhores.
Não tenho dados, mas suspeito que o maior mercado hoje para Java é em aplicativos web, nicho em que as linguagens de script batem forte. C++, nesse mercado, é carta fora do baralho e não é competidor para o Java, arrisco que por esse motivo a Sun está tentando concorrer com as de script
Por outro lado, como as linguagens de script são bastante lentas, a velocidade do Java é um diferencial muito importante.
Embora, sinceramente, a maior parte dos framework “enterprise” no Java mata qualquer pretensão de desempenho in my humble experience
De fato, C++ é carta fora do baralho no mercado web. E java acabou ocupando esse mercado porque na época existia uma carência de boas linguagens estruturadas. Perl tinha o famoso problema do write once, never read it anymore. E as tentativas de invadir o nicho de C++ tinham falhado justamente por esta questão de performance e memória. Mas porque não pensar neste nicho específico agora? Acho muito mais válido do que transformar Java num monstro gigantesco de sintaxe complexa. Quem gosta de linguagem de scripts vai acabar migrando pra Python ou Ruby. Quem não gosta vai acabar não utilizando essas features….
Ronie, a plataforma Java escala tão bem no lado Enterprise, ou seja, grandes servidores de aplicação, que domina a maior fatia deste nicho. Impossivel dizer que java não tem potencial para escalar e muito bem para aplicações deste tipo.
Discordo em gênero, número e grau. É justamente em C/C++, quando o programador tem que manualmente lidar com a alocação de memória que mais temos memory leaks e código mais verboso poluido com o que não faz parte do problema sendo resolvido.
Sei que você não disse isto mas não é porque foi escrito em C/C++ que o uso de memória é automaticamente mais racional. Eu posso escrever sem querer memory leaks em Java (mais dificil) ou em C++ (mais fácil).
Quando eu disse racional, entenda racional da carga de elementos que um programa em C/C++ carrega a priori em relação à carga default carregada por um programa em Java. Óbvio que isto depende da qualidade do programador, e que cometer erros em C é bem mais fácil. Mas eu em geral faço meus comentários pensando em programadores top. E o objetivo final desta frase foi ressaltar o motivo pelo qual Java não teve muito sucesso em um certo nicho.
Lendas urbanas: Custo de alocacao em Java
“Quem aloca memria mais rpido: Java ou C/C++? Lendas urbanas afirmam que C. Ser?”
Realmente um programa sem uma VM contra um que precisa de uma *sempre* irá perder em termos de start-up. Mas sejamos francos, qualquer programa mais sério tem um tempo de startup, se você não estiver falando de applets ou notepads turbinados qualquer programa vai se valer bem da famosa _splash_screen_.
Concordo plenamente que isto gerou um grande preconceito contra a plataforma Java, principalmente antes da sua era _server side_.
Agora, mesmo programadores top precisam suar muito para manualmente gerenciar a memória para cada String usada em um programa *nao brinquedo* em C/C++.
No caso reafirmo: não estou me referindo a notepads o editores de texto. Estou me referindo a sistemas embarcados, sistemas onde performance é critica, sistemas onde memória é limitada. E mesmo em relação a notepads: uma das maiores críticas feitas à JVM é o fato de que até um Hello Word em uma telinha Swing carrega dezenas e dezenas de MB em memória.
PS: Engraçado Bruno, mas quando eu converso com você eu sempre me coloco na posição de criticar a linguagem, apesar de eu gostar. Será ato falho?
Mas é que realmente eu acho que Java não deveria ser comparado falando-se de [Hello Word]s, que é apenas um exemplo didático para sentir um primeiro gosto da ferramenta
Com relação a sistemas embarcados eu realmente não posso falar nada sobre Java ou qualquer outra plataforma pois nunca nem brinquei com isto.
No mais eu queria te parabenizar pelo tópico apresentado velho, é sempre bom discutir com desenvolvedores *top* sobre um assunto tão polêmico, e você sabe que eu adoro uma argumentação polêmica 
Grande abraço!!!
Quanto a você parecer critico ou não Miguel isto deve ser em parte resposabilidade minha pelo meu jeito agressivo de participar destas discussões, ainda mais por escrito e correndo contra o tempo como eu estou
ps. Saudades do wikilunchs ai com o povo da Atech.
Escala sim e escala muito bem. Mas é que eu tenho birra de alguns frameworks enterprise em Java. Algumas vezes uma arquitetura simplória (simplória mesmo, nem sequer simples) resolve o problema mais velozmente e com menos configurações que uma versão “enterprise-like”.
Tudo depende do problema. O problema mesmo é quando a gente pensa que tudo é prego só pq tem um martelo
Dude,
Sistema embedded nunca vai ser algo dominado por Java. Não pela questão de problemas de performance. É mais por uma questão de sistema operacional.
O tal JavaOS nunca pegou no mercado embedded. Celulares, por exemplo, usam o quarteto WindowsCE\Symbian\Linux, além do moribundo Palm OS. A JVM sempre vai “sentar em cima” desses aí, não vai?
Então, qualquer cara mais ou menos espertinho vai querer levar o Java (e qualquer coisa que rode na JVM) sempre na direção de desenvolvimento de aplicações, não para software de base. Performance importa? Importou, mas não mais. Nesse aspecto, já chegamos na fase do “good enough”.
E quer coisa melhor para o desenvolvimento de aplicações que ter tipagem dinâmica, closures e todas essas coisinhas bobinhas que podem servir para um desenvolvedor top criar o próximo killer app?
Miguel, se eu fosse você, eu revia meus conceitos.