Por que as pessoas dizem que Ruby é lento? [fechadas]

Eu gosto do Ruby on Rails e o uso em todos os meus projetos de desenvolvimento web. Alguns anos atrás, houve muita conversa sobre o Rails ser um porco da memória e sobre como ele não foi muito bem dimensionado, mas essas sugestões foram colocadas na cama por Gregg Pollack aqui .

Ultimamente, tenho ouvido pessoas dizendo que o próprio Ruby é lento.

• Por que Ruby é considerado lento?

Não acho o Ruby lento, mas apenas o uso para criar aplicativos CRUD simples e blogs da empresa. Que tipo de projetos eu precisaria fazer antes de encontrar Ruby ficando lento? Ou essa lentidão é apenas algo que afeta todas as linguagens de programação?

• Quais são suas opções como programador Ruby se você deseja lidar com essa "lentidão"?

• Qual versão do Ruby melhor se adequaria a um aplicativo como o Stack Overflow, onde a velocidade é crítica e o tráfego é intenso?

As perguntas são subjetivas e eu percebo que a configuração da arquitetura (EC2 x servidores independentes etc.) faz uma grande diferença, mas eu gostaria de ouvir o que as pessoas pensam sobre o Ruby ser lento.

Finalmente, não consigo encontrar muitas novidades no Ruby 2.0 - presumo que estamos a alguns anos disso?

Por que Ruby é considerado lento?

Porque se você executa benchmarks típicos entre Ruby e outros idiomas, o Ruby perde.

Não acho o Ruby lento, mas apenas o uso para criar aplicativos CRUD simples e blogs da empresa. Que tipo de projetos eu precisaria fazer antes de encontrar Ruby ficando lento? Ou essa lentidão é apenas algo que afeta todas as linguagens de programação?

O Ruby provavelmente não ajudaria você a escrever um aplicativo de processamento de sinal digital em tempo real ou qualquer tipo de sistema de controle em tempo real. Ruby (com as VMs de hoje) provavelmente engasgaria em um computador com recursos limitados, como smartphones.

Lembre-se de que grande parte do processamento em suas aplicações web é realmente feito por software desenvolvido em C. por exemplo, Apache, Thin, Nginx, SQLite, MySQL, PostgreSQL, muitas bibliotecas de análise, RMagick, TCP / IP, etc, são programas em C usados ​​por Ruby . Ruby fornece a cola e a lógica de negócios.

Quais são suas opções como programador Ruby se você deseja lidar com essa "lentidão"?

Mude para um idioma mais rápido. Mas isso tem um custo. É um custo que pode valer a pena. Mas para a maioria dos aplicativos da Web, a escolha do idioma não é um fator relevante, porque não há tráfego suficiente que justifique o uso de um idioma mais rápido, que custa muito mais para ser desenvolvido.

Qual versão do Ruby melhor se adequaria a um aplicativo como o Stack Overflow, onde a velocidade é crítica e o tráfego é intenso?

Outras pessoas responderam a isso - JRuby, IronRuby, REE fará com que a parte do Ruby do seu aplicativo seja executada mais rapidamente em plataformas que podem pagar pelas VMs. E, como muitas vezes não é Ruby que causa lentidão, mas a arquitetura do sistema e a arquitetura do aplicativo, você pode fazer coisas como replicação de banco de dados, vários servidores de aplicativos, balanceamento de carga com proxies reversos, cache HTTP, memcache, Ajax, cache do lado do cliente, etc. Nada disso é Ruby.

Finalmente, não consigo encontrar muitas novidades no Ruby 2.0 - presumo que estamos a alguns anos disso?

A maioria das pessoas está esperando pelo Ruby 1.9.1. Eu mesmo estou esperando o Rails 3.1 no Ruby 1.9.1 no JRuby.

Por fim, lembre-se de que muitos desenvolvedores escolhem o Ruby porque tornam a programação uma experiência mais prazerosa em comparação com outros idiomas e porque o Ruby with Rails permite que desenvolvedores da Web qualificados desenvolvam aplicativos muito rapidamente.

Primeiro de tudo, mais lento em relação a quê ? C? Pitão? Vamos obter alguns números no jogo Benchmarks de linguagem de computador :

• Ruby 1.9 vs. Python3 dentro da mesma ordem de magnitude
• Ruby 1.9 vs. PHP dentro da mesma ordem de magnitude
• Servidor Ruby 1.9 vs. Java 6 até duas ordens de magnitude mais lento !
• Ruby 1.9 vs. C (gcc) até duas ordens de magnitude mais devagar !
• ...

Por que Ruby é considerado lento?

Depende de quem você pergunta. Você poderia ser informado disso:

• Ruby é uma linguagem interpretada e linguagens interpretadas tendem a ser mais lentas que as compiladas
• O Ruby usa a coleta de lixo (embora o C #, que também usa a coleta de lixo, saia duas ordens de magnitude à frente do Ruby, Python, PHP etc. nos benchmarks mais algorítmicos e com menos alocação de memória acima)
• As chamadas ao método Ruby são lentas (embora, devido à digitação do pato, sejam indiscutivelmente mais rápidas do que nas linguagens interpretadas com tipos fortes)
• Ruby (com exceção do JRuby) não suporta multithreading verdadeiro
• etc.

Mas, novamente, lento com relação a quê? O Ruby 1.9 é tão rápido quanto Python e PHP (com um fator de desempenho 3x) quando comparado a C (que pode ser até 300x mais rápido), portanto, o exposto acima (com exceção das considerações de encadeamento, seu aplicativo deve depender muito desse aspecto ) são amplamente acadêmicos.

Quais são suas opções como programador Ruby se você deseja lidar com essa "lentidão"?

Escreva para escalabilidade e jogue mais hardware (por exemplo, memória)

Qual versão do Ruby melhor se adequaria a um aplicativo como o Stack Overflow, onde a velocidade é crítica e o tráfego é intenso?

Bem, o REE (combinado com o Passenger ) seria um candidato muito bom.

Aqui está o que o criador do Rails, David Heinemeier Hansson, tem a dizer:

O Rails [Ruby] é para a grande maioria dos aplicativos Web Fast Enough. Temos sites que fazem milhões de visualizações de página dinâmicas por dia. Se você acabar na página inicial do Yahoo ou da Amazon, é improvável que uma estrutura de prateleira em QUALQUER idioma o ajude muito. Você provavelmente terá que fazer o seu próprio. Mas claro, eu gostaria de ciclos de CPU gratuitos também. Por acaso, me preocupo muito mais com os ciclos de desenvolvedor gratuitos e estou disposto a trocar o primeiro pelo último.

ou seja, jogar mais hardware ou máquinas no problema é mais barato do que contratar mais desenvolvedores e usar uma linguagem mais rápida, mas mais difícil de manter. Afinal, poucas pessoas escrevem aplicativos da Web em C.

O Ruby 1.9 é uma grande melhoria em relação ao 1.8. Os maiores problemas com o Ruby 1.8 são sua natureza interpretada (sem bytecode, sem compilação) e as chamadas de método, uma das operações mais comuns no Ruby, são particularmente lentas.

Não ajuda que praticamente tudo seja uma pesquisa de método no Ruby - adicionando dois números, indexando uma matriz. Onde outras linguagens expõem hacks ( __add__método do Python , overload.pm do Perl), o Ruby faz OO puro em todos os casos, e isso pode prejudicar o desempenho se o compilador / intérprete não for suficientemente inteligente.

Se eu estivesse escrevendo um aplicativo da web popular em Ruby, meu foco seria o cache. O armazenamento em cache de uma página reduz o tempo de processamento dessa página para zero, independentemente do idioma que você estiver usando. Para aplicativos da Web, a sobrecarga do banco de dados e outras E / S começam a importar muito mais do que a velocidade do idioma, portanto, eu me concentraria em otimizar isso.

A escrita do código é lenta. O código de leitura está lento. A localização e a correção de erros é lenta. A adição de recursos e aprimoramentos é lenta. Tudo o que melhorar no anterior é uma vitória. Muito raramente, o desempenho da execução é um problema.

A resposta é simples: as pessoas dizem que o ruby ​​é lento porque é lento com base em comparações medidas com outros idiomas. Lembre-se, porém, que "lento" é relativo. Freqüentemente, o ruby ​​e outras línguas "lentas" são bastante rápidas o suficiente.

Joel on Software - Ruby Performance Revisited explica muito bem. Pode estar desatualizado ...

Eu recomendaria ficar com ele como você está acostumado ao Ruby on Rails,
se você encontrar um problema de desempenho, poderá reconsiderar o uso de uma linguagem e estrutura diferentes.

Nesse caso, eu realmente sugeriria C # com o ASP.NET MVC 2 , funciona muito bem para aplicativos CRUD.

Eu diria que Ruby é lento porque não foi feito muito esforço para tornar o intérprete mais rápido. O mesmo se aplica ao Python. Smalltalk é tão dinâmico quanto Ruby ou Python, mas tem um desempenho melhor em magnitude: veja http://benchmarksgame.alioth.debian.org . Como o Smalltalk foi mais ou menos substituído por Java e C # (isso é há pelo menos 10 anos atrás), não foi feito mais trabalho de otimização de desempenho e o Smalltalk ainda é muito mais rápido que Ruby e Python. As pessoas da Xerox Parc e da OTI / IBM tinham dinheiro para pagar as pessoas que trabalham para tornar o Smalltalk mais rápido. O que não entendo é por que o Google não gasta dinheiro para tornar o Python mais rápido, pois é uma grande loja de Python. Em vez disso, gastam dinheiro no desenvolvimento de linguagens como Go ...

Primeiro de tudo, você se importa com o que os outros dizem sobre o idioma que você gosta? Quando faz o trabalho que precisa, você está bem.

OO não é a maneira mais rápida de executar código, mas ajuda na criação do código. Código inteligente é sempre mais rápido que código estúpido e loops inúteis. Sou um DBA e vejo muitos desses loops inúteis, soltá-los, usar códigos e consultas melhores e o aplicativo é mais rápido, muito mais rápido. Você se importa com o último microssegundo? Você pode ter idiomas otimizados para velocidade, outros apenas fazem o trabalho que precisam e podem ser mantidos por muitos programadores diferentes.

É tudo apenas uma escolha.

Obviamente, falando sobre velocidade, Ruby perde. Embora testes de benchmark sugiram que Ruby não é muito mais lento que PHP. Mas, em troca, você está obtendo código DRY de fácil manutenção, o melhor de todas as estruturas em vários idiomas.

Para um projeto pequeno, você não sente lentidão (quero dizer, até <50K usuários), uma vez que nenhum cálculo complexo é usado no código, apenas o material principal.

Para um projeto maior, pagar pelos recursos compensa e é mais barato que os salários dos desenvolvedores. Além disso, escrever código no RoR é muito mais rápido do que qualquer outro.

Em 2014, essa magnitude da diferença de velocidade da qual você está falando é insignificante para a maioria dos sites.

A maneira de lidar com o desempenho do Ruby no aplicativo Web é a mesma de qualquer outra linguagem de programação:

ARQUITETURA

Isso é mais fácil no Rails do que na maioria dos outros frameworks da Web.

No nível do aplicativo , armazenando em cache o que deveria ser armazenado em cache e gerenciando o acesso ao banco de dados de maneira inteligente (já que o gargalo geralmente está no acesso "DB" para a maioria dos aplicativos WEB).

O Rails torna muito fácil e natural resolver esses problemas. Existem várias abstrações para armazenar em cache dados, páginas e fragmentos , e também existem abstrações muito boas para lidar com a parte SQL de maneira otimizada e reutilizável ( Active Record e AREL ).

Esta é a razão pela qual tantas aplicações escritas em linguagens mais rápidas e não tão expressivas (como php) acabam sendo mais lentas que as contrapartes do Ruby. Não é tão fácil e elegante lidar com o cache e as consultas com esses idiomas do que com o Ruby.

No nível da infraestrutura , é razoável pensar no balanceamento de carga e em todas essas coisas que eu não conheço muito. Eu terceirizava esse problema contratando alguma plataforma como provedor de serviços, como Heroku ou Engine Yard . De qualquer forma. A implantação de trilhos com balanceamento de carga provavelmente não é muito difícil de fazer.

O Ruby é mais lento que o C ++ em várias tarefas facilmente mensuráveis ​​(por exemplo, executar código fortemente dependente do ponto flutuante). Isso não é muito surpreendente, mas justificativa suficiente para algumas pessoas dizerem que "Ruby is Slow" sem qualificação. Eles não contam o fato de que é muito mais fácil e seguro escrever código Ruby que C ++.

A melhor solução é usar módulos de destino escritos em outro idioma (por exemplo, C, C ++, Fortran) no seu código Ruby. Eles podem fazer o trabalho pesado e seus scripts podem se concentrar em questões de coordenação de nível superior.

O desempenho é quase sempre sobre um bom design e interações de banco de dados otimizadas. Ruby faz o que a maioria dos sites precisa com bastante rapidez, especialmente versões mais recentes; e a velocidade do desenvolvimento e a facilidade de manutenção oferecem uma grande recompensa em custos e em manter os clientes satisfeitos. Acho que o JAVA tem desempenho de execução lento para algumas tarefas e, dada a dificuldade de desenvolvimento em JAVA, muitos desenvolvedores criam aplicativos lentos, independentemente da capacidade de velocidade teórica, conforme demonstrado nos benchmarks (os benchmarks geralmente são inventados para mostrar uma capacidade específica e estreita). Quando preciso de processamento intensivo que não seja adequado aos recursos do meu banco de dados, escolho C ou Objective-C ou alguma outra linguagem compilada de alto desempenho para essas tarefas, dependendo da plataforma. Se eu precisar criar um aplicativo Web baseado em banco de dados, Eu uso o RoR ou, às vezes, o C # ASP.NET, dependendo de outros requisitos; porque todas as plataformas têm pontos fortes e fracos. A velocidade de execução das coisas que seu aplicativo faz é importante, mas, afinal, se o desempenho de execução de um aspecto restrito de uma linguagem é tudo o que importa; então eu ainda posso estar usando a linguagem Assembler para tudo.

As pessoas dizem que Ruby é lento porque compara programas Ruby a programas escritos em outros idiomas. Talvez os programas que você escreve não precisem ser mais rápidos. Talvez para os programas que você escreve Ruby não seja o gargalo que está atrasando as coisas.

Ruby 2.1 comparado ao Javascript V8

Ruby 2.1 comparado ao Lua comum

Ruby 2.1 comparado ao Python 3

Ruby tem bom desempenho para a produtividade do desenvolvedor. O Ruby por natureza força o desenvolvimento orientado a testes devido à falta de tipos. Ruby tem bom desempenho quando usado como um wrapper de alto nível para bibliotecas C. O Ruby também tem bom desempenho durante processos de execução longa, quando é compilado por JIT para o código da máquina via JVM ou Rbx VM. O Ruby não tem um bom desempenho quando é necessário triturar números em um curto espaço de tempo com código ruby ​​puro.