[quote=juliocbq]Essa otimização é relevante somente em pequenos algoritmos. Com o aumento da complexidade dos objetos o Java tende a perder desempenho porque todos os métodos e variáveis São declarados como virtuais e tudo acaba sendo alocado no heap. Isso gera um consumo de memória grande e consequente perda de desempenho no processamento. Existe um artigo interessante na wiki sobre isso.
http://en.m.wikipedia.org/wiki/Comparison_of_Java_and_C++[/quote]
Um dos graves problemas do Java é mesmo o consumo de memória. Muitas estratégias dele para ganhar performance envolvem caches.
Outro problema é o fato do garbage collector literalmente congelar a aplicação por alguns milissegundos, enquanto trabalha.
Agora, eu discordo com vc de que essas otimizações sejam válidas só em pequenos algorítimos. Não é incomum ver programadores C++ que usam o new e delete default, e isso gera um penaulty grave para performance. Você até pode contornar em alguns casos, mas em outros, pode ser que o código problemático esteja encapsulado numa biblioteca, e você só descubra tarde demais, ou esteja impossibilitado de substituí-la. Também é bastante fácil ser descuidado com I/O ao usar o fstream, sem se preocupar em você mesmo criar um cache (no java, qualquer programador jr. sabe criar seu BufferedInputStream).
Por isso costumo dizer que o C++ é mais otimizável que o Java, mas não necessariamente mais otimizado. O fato é que, se duas equipes gastarem esforços, um programa C++ certamente será algumas vezes mais rápido que um programa Java. Porém, o esforço para isso no C++ é gigantesco, exige um time experiente, horas de desenvolvimento e benchmarking e, portanto, tem um custo muito alto. Erros no C++ também podem ter um impacto muito mais sobre o desempenho. Vai ter sentido apenas em empresas que trabalham com tempo real: vídeo, jogos, etc.
Outro ponto positivo do Java, em termos de construir aplicações com performance, são os profilers. O fato de ter muita informação de contexto (graças ao reflection) e de ter a VM, permite que profilers excelentes sejam criados. E o melhor, profilers não intrusivos, que não exigem qualquer modificação em seu código. Nós mesmos somos bastante fãs do Visual VM e do profiler do Netbeans, ambos fornecidos de graça. E nem adianta falar do Valgrind. Ele é só para Linux e nem se compara a um profiler Java.
Agora vem o detalhe mais importante dessa discussão: Essa diferença de performance gera impacto perceptível na aplicação? Porque não adianta nada falarmos de performance da linguagem, se isso não for percebido pelo usuário. Em 90% dos casos, não. Só valerá a pena se preocupar com a linguagem em si, caso você trabalhe com sistemas de tempo real, críticos. Audio, vídeo, games, sistemas industriais, são exemplos de sistema assim. Ou seja, sistemas que são intensamente CPU Bound, que dependam muito de processamento puro e simples, e não irão perder tempo em I/O, rede, etc.
Para um servidor de rede você tem um gargalo gigante, que é a própria rede em si. Para uma aplicação comercial, os gargalos geralmente irão se concentrar no BD. Até por isso o PHP, que é uma linguagem extremamente lenta, tem aplicações ótimas e rápidas, como o Wordpress, simplesmente porque não adianta falar de performance, se não estivermos falando em otimização de gargalos. O fato é que a linguagem dificilmente será o gargalo, e tirando aplicações como as que eu e você desenvolvemos, acho que a maior parte do fórum jamais sequer terá a necessidade de migrar um código Java para um C++.