Java, é rápido em processamento interno?

O java é rápido. Muito rápido mesmo. Não perde em quase nada para o C e certamente nada para o Delphi.

A parte do código muito usada é compilada pela HotSpot VM, não interpretada o tempo todo.O compilador hotspot também consegue fazer inline de funções muito usadas em tempo de execução, o que torna o código muito rápido.

Além disso ele te fornecer uma API, cheia de classes otimizadas, com algoritmos que dariam muito trabalho de se implementar na mão. Como é o caso dos maps, ou do método sort() da classe Collections. As chances de você usar algo mais burro e menos testado em C é muito alta, a menos que você dependa de bibliotecas como a STL.

Outra vantagem é que existem diversas e ótimas ferramentas de profiling gratuitas para o Java. Assim, você pode executar sua aplicação algumas vezes, medindo tempo que cada método leva e otimizando as partes críticas do código, onde os gargalos são realmente significativos.

Não conheço VFP (a não ser que isso seja abreviação de Visual FoxPro), mas realmente a diferença é muito grande. Pode ser o caso de analisar a execução para descobrir algum gargalo, de repente há algo errado no programa em si.

Desempenho, na maioria dos casos, é um problema do programa, não da linguagem.

Existem certos detalhes com laços for ou while, independente de linguagem…

:arrow: Não declare variáveis dentro do laço

Errado

for(int i = 1; i &lt 10; i++){
   double a = 1 / i;
   System.out.println(a);
}

Certo

double a;
for(int i = 1; i &lt 10; i++){
   a = 1 /  i;
}

:arrow: Evite usar muitos loops aninhados. O crescimento do esforço computacional nestes casos é exponencial. Um loop a mais e vc estará multiplicando este esforço pelo número de iterações do seu laço.

:arrow: Quando não valer mais a pena, caia fora! Muitas vezes estamos fazendo um loop que depende de mais de uma situação e uma delas pode surgir a qualquer momento, o que é checado dentro do código. Quando isso acontecer, use break

:arrow: A idéia complementar ao caso acima é o uso do continue. Às vezes você tem um trecho de código dentro do laço que, caso uma determinada condição não seja satisfeita, não deve ser executado, ou melhor, caso seja executado não fará diferença alguma, processamento desperdiçado. Com continue você volta ao inicio do laço. Sai mais barato para o computador do que encher de if

:arrow: Quando for usar estruturas if/else dentro do laço, coloque para ser testada sempre a opção com maior probabilidade de ocorrer. Sempre que um if retorna falso e o else deve ser executado há um esvaziamento de pipeline do processador, o que torna tudo mais lento…

:arrow: Muitas vezes seu laço está fazendo um trabalho inútil que poderia facilmente ser substituído por uma fórmula. Já trabalhei com métodos numéricos e te garanto que isso acontece com frequência…

#@®®¡$:

Não conheço VFP (a não ser que isso seja abreviação de Visual FoxPro), mas realmente a diferença é muito grande. Pode ser o caso de analisar a execução para descobrir algum gargalo, de repente há algo errado no programa em si.

Desempenho, na maioria dos casos, é um problema do programa, não da linguagem.

Realmente o desempenho geralmente esta ligado na programação, porém, mesmo fazendo todas as alterações e aprimoramentos no meu script, percebo que é a diferença ainda esta muito grande.

E já que estou fazendo algumas soluções web, e fui conhecendo o verdadeiro tamanho do Java, pensei: será que não esta aqui a solução para um script complexo?

Obrigado também Cassio. - tuas dicas são muito válidas pra mim.

Em linguagens como as de hoje, os otimizadores já implementam boa parte do que o Cassio citou. Portanto, você não deve ter problemas com isso, exceto em linguagens de script totalmente interpretadas (diferentemente do Java, onde o .class é uma compilação).

Por isso, fique atento aos algoritmos usados e use um profiler para medir o desempenho de sua aplicação, método a método, identificar os gargalos e melhorar o código nos trechos problemáticos.