Por que as pessoas ainda dizem que o Java é lento? [fechadas]

Durante muito tempo no SO e em outros lugares, o Java tem a reputação de ser lento. De piadas a muitos comentários em perguntas e respostas, as pessoas ainda acreditam que o Java é lento com base apenas na experiência com ele nos anos 90.

Este é o meu problema: refutamos (a maioria) os motivos pelos quais as pessoas acreditam que o Java é lento. Fora das pequenas coisas, o Java é bem rápido.

Então, por que as pessoas ainda se recusam a acreditar que o Java é rápido agora? Faz parte da mentalidade deles que algo que não seja C / C ++ seja lento? É porque as pessoas não verificam com o tempo? É porque as pessoas são apenas tendenciosas?

São as aplicações. Como você notar, que têm provado, uma e outra vez, que em cenários artificiais código Java pode atender ou até mesmo bater o desempenho das chamadas línguas "de elevada performance" como C, C ++, Lisp, VB6, ou JavaScript. E, quando apresentados com essa evidência, a maioria dos oponentes de mente aberta e sensatos pendura a cabeça na vergonha e promete nunca mais espalhar essa calúnia.

... mas, então, eles iniciam o Eclipse, o NetBeans ou o Guiffy, ou ativam o suporte a Java no navegador ou tentam executar um aplicativo em seu telefone de recurso favorito. E eles esperam que ele se torne responsivo ...

... e espere ...

... e espere ...



... e espere ...







... e espere ...











... e ...




... o que prometi nunca mais fazer de novo ? Desculpe, deve ter cochilado ...

Esta questão opera em premissas falsas: onde conta, o Java ainda é lento. Onde conta são algoritmos pesados ​​de computação em grandes conjuntos de dados. Concedido, eles podem ser otimizados, às vezes para estarem em pé de igualdade com o código C / C ++, mas apenas ao custo da modularidade e da genéricaidade. O código C ++ eficiente pode ser projetado para ser genérico e utilizável como uma biblioteca de uso geral. O código Java não pode. Veja o Array.sortmétodo altamente otimizado , que usa implementações diferentes para todos os tipos fundamentais e cuja variante de objeto ainda é muito mais lenta que a genérica do C ++, sortporque esses objetos precisam despachar comparações de igualdade dinamicamente.

É verdade que as otimizações pontuais realizadas pelo mecanismo do HotSpot podem realmente prever o destino dessas chamadas virtuais e tentar inlining. Mas isso ainda é mais lento que a chamada diretamente embutida que é despachada no sortmétodo C ++ ' .

Um ex-colega meu fez comparações comparativas de um problema em grandes conjuntos de dados ( contagem do diagrama- q usando formas dinâmicas) com uma implementação C ++ modelada e uma implementação Java orientada a objetos. O código Java tinha ordens de magnitude mais lentas que o código C ++.

Claro que isso está comparando maçãs com laranjas. Mas o ponto é que a implementação em Java foi a melhor implementação possível (em termos de desempenho, dado o grau de modularidade necessário para uma biblioteca), e a implementação em C ++ também.

Infelizmente, os dados de referência não estão disponíveis gratuitamente, mas outros encontraram números semelhantes ao comparar a sobrecarga da abstração de tempo de execução. Por exemplo, Scott Meyers escreve em Effective STL sobre a sobrecarga da qsortfunção genérica de C :

A classificação de C ++ praticamente sempre embaraça o qsort de C quando se trata de velocidade. […] Em tempo de execução, a classificação faz chamadas inline para sua função de comparação ... enquanto o qsort chama sua função de comparação através de um ponteiro. […] Nos meus testes com um vetor de um milhão de vezes, [classificar] foi até 670% mais rápido…

Porque é lento ... em algumas aplicações. Os aplicativos de desktop precisam responder desde o início e a sobrecarga de inicialização conta como lenta.

Por outro lado, se você executa um servidor, não importa se há algum aquecimento (análise e compilação do JIT) - você faz isso uma vez na lua azul; portanto, na maioria das vezes, não pode ser considerado totalmente lento.

Eu diria que é porque quando as pessoas o encontraram pela primeira vez, foi lento. Com base nisso, eles formaram uma impressão disso. É improvável que essa impressão mude se não a usarem e não a usarem por causa dessa impressão - é um ciclo vicioso.

Devo admitir que tive a impressão de que o Java era lento e, sim, isso foi da minha exposição anterior a ele. Agora mudei para linguagens diferentes e tive uma exposição extremamente limitada ao Java desde então. Consequentemente, minha opinião não mudou muito.

Porque leva uma geração para mudar a percepção das pessoas sobre um produto

Não tem nada a ver com a rapidez com que o Java se torna. Na mente das pessoas, Java é um identificador const associado à palavra "lento". Há pouco, nada que você ou a Oracle possa fazer sobre isso.

Fique feliz por o Oracle não ter destruído a cultura de programação Java (ainda) fazendo algo imprudente ou estúpido . Como cobrar custos excessivos de licenciamento para usá-lo. Ou processando pessoas com base em patentes de software anteriormente pertencentes à Sun. ::suspiro::

Eu odeio ser o pessimista aqui, mas, a menos que a Oracle e o Google resolvam a luta do Java em bons termos, ou o Google seja forçado a comprar o Java e a torne uma plataforma de código aberto 'adequada', o Java está no caminho de ser o garoto. o playground que tem piolhos. Ou seja, ninguém vai querer tocá-lo com um poste de 20 pés.

Nota: Só para esclarecer, quando digo geração, estou falando em termos de pessoas e não de computador. Ou seja, até que as pessoas que sustentam essa percepção morrem de velhice ou sejam substituídas por uma geração mais jovem, a percepção será verdadeira. Pense em termos de 5 décadas e não 5 anos.

Uma razão é que as pessoas confiam no que os outros dizem e não no que veem .

De acordo com o que me disseram quando comecei a programar, o Java é "mais lento" que o C ++, e a razão pela qual o Java pode ser usado é porque é "conveniente e fácil". Acredita-se muito comum que Java traga Segurança e conveniência, ao custo de desempenho. Mesmo quando o C # é inventado posteriormente, as pessoas acreditam que é mais rápido que o Java porque é "nativo".

Mas a verdade que as pessoas vêem sem perceber é que, eclipse, o IDE criado com Java, é absolutamente o IDE MAIS RÁPIDO da classe. Eu usei quase todos os IDEs de fluxo principal, os de MS e GNU, Borland ..., o eclipse é o rei absoluto dos IDEs, principalmente por ser rápido.

Outro motivo é o longo tempo de inicialização .

Java não é adequado para o desenvolvimento de um aplicativo minúsculo que permanece na bandeja do sistema, consome um pouco de memória, abre uma caixa de diálogo lembrando que você deve fazer uma pausa; ou um bloco de notas usado para abrir um arquivo de texto, leia-o e feche-o. Ele deve ser usado em algo GRANDE, como um servidor Web sempre disponível, faça uso otimizado do seu recurso de computação e responda a milhões de solicitações a cada hora. Ou um IDE como o eclipse que gerencia milhares de arquivos da área de trabalho. Você não sabe que o aplicativo Java é rápido até que ele seja executado por pelo menos várias horas, eu acredito.

@bigown "Por que as pessoas ainda dizem que o Java é lento?"

Porque eles são burros. Porque eles não têm experiência de trabalho, mas pensam que são a encarnação viva de Dikjstra ou a segunda vinda de Linus Torvald, oh não sei. As razões para dizer uma coisa tão retardada são muitas, mas geralmente a estupidez, o fanboyismo subjetivo irracional e a prostituição emocional parecem estar por trás deles.

Vamos desativar isso para que você possa ver a verdade do que acabei de dizer acima:

Primeiro, o que é lento, em que contexto, para que, em que condições, com que finalidade de engenharia / científico / negócios (dizer que é péssimo não é um deles). Qualquer pessoa que disser "X é lento" para qualquer tecnologia X, ou simplesmente "X é Y", onde Y é algum tipo de afirmação negativa, sem responder a nenhuma das perguntas acima, deve ser descartado como um tolo. Declarações como essa não têm lugar na engenharia. Na política e nas salas de bate-papo juvenil, talvez, mas não na engenharia.

Segundo, a maioria desses tolos mal orientados reclama que o Java é lento porque o ZOMG leva o seu eclipse para sempre (gee, carrega a coisa com todos os plug-ins e adivinha o que acontece.) A maioria desses tolos nem sabe como para ajustar a jvm para que o eclipse opere rapidamente (ou para qualquer aplicativo Java). Ou seja, eles não têm idéia do ajuste de desempenho, que é uma realidade não apenas para Java, mas para qualquer sistema não trivial, seja hardware ou software. Então, ali mesmo, eles se desarmam por qualquer validade técnica ao fazer tais declarações irracionais.

Terceiro, vamos considerar para que serve a maior parte do desenvolvimento Java: back-end OLTP em primeiro lugar; sistemas de monitoramento em segundo lugar. Qualquer um dos tipos de sistema deve ser executado em clusters e ininterrupto por semanas, se não meses. Realmente importa, então, que seu pequeno eclipse ou aplicativo de brinquedo leve um ou dois minutos para carregar quando o objetivo dos aplicativos Java REAL é executado por longos períodos de tempo? Contexto, pessoas, contexto.

Por fim, a espinha dorsal do OLTP no Google e no Ebay roda em Java. Eu consideraria isso uma prova por contradição de que o Java não é lento (pelo menos para condições importantes, não para pequenas experiências com brinquedos, benchmarks e evidências anedóticas inverificáveis ​​feitas especificamente com o objetivo de dizer "o X é lento, é uma merda".

Há engenharia e há fanboyismo. Adivinhe a que declarações de categoria como essas pertencem?

Porque é, podemos fechar esse tópico de uma vez por todas?

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf [role para tabelas, o Java é 3,7 a 12,6 vezes mais lento que o C ++, pesquisa realizada por funcionários do Google]

PS: Se não estiver, me dê um nome de pelo menos um aplicativo Java ágil para começar, nunca o vi antes.

TMHO, isso ocorre devido ao tempo necessário para iniciar a VM no navegador. Se um aplicativo iniciar lentamente, as pessoas só se lembrarão disso. Porque, o longo tempo de início é realmente irritante. Realmente. Um dos meus colegas de trabalho me disse que não usa o Firefox porque é muito lento. (?!?). Mas, sim, ok, no Windows, o Firefox leva uma quantidade enorme de tempo para aparecer. Segundo ele, este aplicativo é lento, ele decidiu sobre a velocidade geral dele.

Lento comparado com o que? Estou pensando em mudar de Ruby comum para JRuby (ruby baseado em Java) porque ouvi dizer que é mais rápido.

Opiniões são opiniões, e fatos são fatos.

Aqui está um fato do Google Code Jam, que desafia os programadores a resolver problemas difíceis de computação em um curto período de tempo, o que significa que o desempenho do idioma usado desempenha um papel importante:

Nas edições anteriores (2009, 2010, 2011), cerca de 75% dos programadores que chegaram às rodadas finais estavam usando C ++, em vez de cerca de 15% usando Java.

Fonte -> http://www.go-hero.net/jam/

Por volta de 1997, usei o HP Vectra VE (200 MHz) e o Windows 95. A maioria dos aplicativos rodou muito rápido nisso, mas tentei alguns aplicativos escritos em Java (IDEs, se bem me lembro). Eles eram muito lentos, pelo menos as partes da GUI deles. Eles demoraram muito tempo para começar e os elementos da GUI (por exemplo, menus) não foram muito responsivos - houve atrasos no feedback visual. Além disso, como os aplicativos Java GUI tinham (tem) uma aparência bastante distinta, aprendi a associar essa aparência (e Java) a um desempenho ruim.

Depende do que você quer dizer com ser lento.

Primeiro de tudo, o java fez muitos progressos recentemente e é muito rápido na maioria dos casos. Mas :

• Java é lento na inicialização, porque você precisa carregar a JVM antes de fazer qualquer coisa.
• Alguns recursos de segurança podem prejudicar o desempenho em alguns casos. A verificação limitada com acesso aleatório é um exemplo.
• Faça com que algo realmente rápido em java exija trabalhar com a JVM (para tirar proveito da linha de cache, por exemplo).
• A falta de metaprogramação implica uma penalidade no tempo de execução com cada abstração, portanto o desempenho chega ao custo do design em muitos casos.
• O Java dificilmente pode garantir restrições em tempo real - por design - e isso pode ser considerado como “lento” por algumas pessoas.

A propósito, o java é, em alguns casos, mais rápido que o C / C ++ de baunilha. Mas essas linguagens oferecem as ferramentas para ajustá-las.

Java é uma linguagem de programação voltada para a produtividade. Agora, é rápido o suficiente para a maioria dos aplicativos, mas não é suficiente para alguns outros.

Em geral, a lentidão do Java é um argumento usado em excesso porque é irrelevante na maioria dos casos.

O código Java canônico simples tende a ser parecido ou mais rápido que o código C / C ++ / D canônico simples. O código canônico simples tende a executar muitas alocações de memória desnecessariamente, não é particularmente ajustado a qualquer arquitetura de CPU, não tem toneladas de otimizações de baixo nível, etc. O HotSpot GC do Java não é nada menos que incrível, e as otimizações de VM tendem ser melhor do que o que um compilador estático poderia fazer.

Por outro lado, se você realmente precisa de desempenho e deseja ajustar manualmente as coisas para obtê-lo, o C / C ++ / D oferece muito mais oportunidades para isso. Você não pode usar o assembler embutido em Java. Você não pode usar truques de punção do tipo sujo para tratar números de ponto flutuante como matrizes de bits. Você não pode usar esquemas de gerenciamento de memória personalizados que podem ser mais rápidos que o GC para o seu caso de uso específico. Você não pode alocar quase tanto na pilha em Java quanto em C / C ++ / D. Em Java, a única maneira de obter algo aproximadamente equivalente a funções de ordem superior é com interfaces e ligação de tempo de execução. Em D e (acho, me corrija se estiver errado) em C ++, você pode passar funções para modelos, permitindo que a ligação ocorra em tempo de compilação sem perda de flexibilidade.

Outro ponto para a "lentidão" do Java é o tempo de execução de 64 bits.

Ouvi algumas pessoas reclamarem que o Java é muito lento para elas em computadores de 64 bits. Como se vê, o tempo de execução Java de 64 bits usa a JVM do servidor, que compila todo o programa antes de iniciar.

A seguir, há uma explicação sobre o motivo pelo qual a VM de 64 bits começa mais lentamente.

Por exemplo no Windows:

C:\> java -version  
java version "1.6.0_21"  
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)  
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)  

O desempenho do Java é muito subjetivo, no entanto, a percepção de por que o Java é lento é em grande parte por razões que outros observaram: a percepção da maioria das pessoas sobre algo é colorida por sua experiência anterior com ele e o Java nem sempre foi uma linguagem bem otimizada. o capuz. Da mesma forma, o Eclipse de baunilha não é exatamente um IDE rápido para trabalhar e empalidece em termos de capacidade de resposta quando comparado a um IDE como o Visual Studio.

Porém, fora dos problemas de interface do usuário que o Java tem na inicialização, ele é rápido o suficiente para a maioria dos aplicativos. Se você pesquisar, poderá encontrar artigos que o comparem com outros idiomas e a maioria dos resultados apresentados coloca-o no intervalo em que somente será um problema quando você estiver lidando com os principais conjuntos de dados.

No campo da bioinformática, ele é usado um pouco, pois é bem suportado e já existe uma base de instalação, uma das vantagens que o Java tem é que você pode fazer um desenvolvimento bastante rápido com ele que não pode fazer com C Se você observar as linguagens usadas para bioinformática (eu pessoalmente uso R, Python e Java regularmente), notará que nenhuma delas é exatamente a mais rápida e não é incomum que os conjuntos de dados em bioinformática cheguem aos 100 anos. de gigabytes de informação. No final do dia, o tempo humano ainda é mais valioso e, embora as diferenças de velocidade sejam perceptíveis, o tamanho dos conjuntos de dados tende a ser grande o suficiente para serem executados da noite para o dia.

Se fosse mais fácil escrever uma interface de usuário rápida em Java, é bem provável que a percepção de velocidade caia do radar, pois a maioria das pessoas não pressiona linguagens o suficiente para que a velocidade seja realmente um problema diário.

Para jogar uma moeda sem valor, acho que os webapps Java geralmente têm longos tempos de inicialização e resposta, onde me parece que Python ou Ruby teriam se saído melhor.

Eu uso o Eclipse na maior parte da minha programação e devo dizer que o Java é tão rápido quanto qualquer outra coisa, se não mais rápido, executando localmente e "autônomo".

Eu diria que o Java é infinitamente lento, não apenas lento, porque falha em resolver problemas simples e fáceis em linguagens reais de alto nível.

Deixe-me dar um exemplo simples. Existe uma otimização simples que se aplica ao mapear uma lista duas vezes, chamada desmatamento: eis a regra para isso, escrita na minha língua Felix:

reduce deforest[T,U,V] (f:T->U, g:U->V, x:list[T]): 
  map g (map f x) => map (compose(g,f)) x
;

que diz: em vez de mapear a lista x com f, em seguida, mapeá-la novamente com g, exigindo duas passagens da lista e criando uma lista temporária de lixo, apenas mapeie a lista com a composição das funções.

Essa é uma otimização de alto nível muito mais significativa que o desempenho de baixo nível da Java JVM. A especificação que eu dei acima não é apenas uma sintaxe bonita, esta é uma instrução escrita pelo usuário dizendo ao compilador Felix como executar uma otimização.

Por favor, mostre-me como fazer esse tipo de coisa em Java. Não? Então o Java é lento. Muito devagar. [Haskell pode fazer isso automaticamente, acredito].

E antes que você diga "mas Java é uma linguagem OO, esse tipo de otimização não se aplica" ... bem, esse é exatamente o meu ponto. Java é péssimo, e ser OO é um dos principais motivos.

A otimização de JIT nunca chega nem perto de competir com os tipos de otimizações que um compilador decente pode fazer.