Perché la gente dice che Ruby è lento? [chiuso]

Mi piace Ruby on Rails e lo uso per tutti i miei progetti di sviluppo web. Qualche anno fa si parlava molto del fatto che Rails fosse un porco di memoria e di come non si ridimensionasse molto bene, ma questi suggerimenti sono stati messi a punto da Gregg Pollack qui .

Ultimamente, però, ho sentito persone dire che lo stesso Ruby è lento.

• Perché Ruby è considerato lento?

Non trovo che Ruby sia lento ma, di nuovo, lo sto solo usando per creare semplici app CRUD e blog aziendali. Che tipo di progetti dovrei fare prima di scoprire che Ruby sta diventando lento? O questa lentezza è solo qualcosa che influenza tutti i linguaggi di programmazione?

• Quali sono le tue opzioni come programmatore di Ruby se vuoi affrontare questa "lentezza"?

• Quale versione di Ruby si adatterebbe meglio ad un'applicazione come Stack Overflow in cui la velocità è critica e il traffico è intenso?

Le domande sono soggettive e mi rendo conto che l'installazione architettonica (server EC2 vs server autonomi ecc.) Fa una grande differenza, ma mi piacerebbe sapere cosa pensa la gente del fatto che Ruby sia lento.

Infine, non riesco a trovare molte notizie su Ruby 2.0 - suppongo che ci vorranno ancora alcuni anni?

Perché Ruby è considerato lento?

Perché se si eseguono benchmark tipici tra Ruby e altre lingue, Ruby perde.

Non trovo che Ruby sia lento ma, di nuovo, lo sto solo usando per creare semplici app CRUD e blog aziendali. Che tipo di progetti dovrei fare prima di scoprire che Ruby sta diventando lento? O questa lentezza è solo qualcosa che influenza tutti i linguaggi di programmazione?

Ruby probabilmente non ti servirebbe bene a scrivere un'applicazione di elaborazione del segnale digitale in tempo reale o qualsiasi tipo di sistema di controllo in tempo reale. Ruby (con le VM di oggi) probabilmente soffocerebbe su un computer con risorse limitate come gli smartphone.

Ricorda che gran parte dell'elaborazione sulle tue applicazioni web viene effettivamente eseguita da software sviluppato in C. es. Apache, Thin, Nginx, SQLite, MySQL, PostgreSQL, molte librerie di analisi, RMagick, TCP / IP, ecc. Sono programmi C utilizzati da Ruby . Ruby fornisce la colla e la logica aziendale.

Quali sono le tue opzioni come programmatore di Ruby se vuoi affrontare questa "lentezza"?

Passa a una lingua più veloce. Ma questo comporta un costo. È un costo che può valerne la pena. Ma per la maggior parte delle applicazioni web, la scelta della lingua non è un fattore rilevante perché non c'è abbastanza traffico che giustifica l'uso di una lingua più veloce che costa molto di più per lo sviluppo.

Quale versione di Ruby si adatterebbe meglio ad un'applicazione come Stack Overflow in cui la velocità è critica e il traffico è intenso?

Altre persone hanno risposto a questo: JRuby, IronRuby, REE renderanno la parte Ruby della tua applicazione più veloce su piattaforme che possono permettersi le VM. E poiché spesso non è Ruby a causare lentezza, ma l'architettura del sistema del computer e l'architettura delle applicazioni, puoi fare cose come la replica di database, più server di applicazioni, bilanciamento del carico con proxy inversi, cache HTTP, memcache, Ajax, cache sul lato client, ecc. Nessuna di queste cose è Ruby.

Infine, non riesco a trovare molte notizie su Ruby 2.0 - suppongo che ci vorranno ancora alcuni anni?

Molte persone stanno aspettando Ruby 1.9.1. Io stesso aspetto Rails 3.1 su Ruby 1.9.1 su JRuby.

Infine, tieni presente che molti sviluppatori scelgono Ruby perché rende la programmazione un'esperienza più gioiosa rispetto ad altre lingue e perché Ruby con Rails consente agli sviluppatori web esperti di sviluppare applicazioni molto rapidamente.

Prima di tutto, più lento rispetto a cosa ? C? Pitone? Prendiamo alcuni numeri nel gioco dei benchmark dei linguaggi informatici :

• Ruby 1.9 vs. Python3 nello stesso ordine di grandezza
• Ruby 1.9 vs. PHP nello stesso ordine di grandezza
• Ruby 1.9 vs Java 6 server fino a due ordini di grandezza più lenti !
• Ruby 1.9 vs. C (gcc) fino a due ordini di grandezza più lentamente !
• ...

Perché Ruby è considerato lento?

Dipende a chi lo chiedi. Si potrebbe dire che:

• Ruby è un linguaggio interpretato e le lingue interpretate tenderanno ad essere più lente di quelle compilate
• Ruby usa la garbage collection (sebbene C #, che usa anche la garbage collection, esce due ordini di grandezza davanti a Ruby, Python, PHP ecc. Nei benchmark più algoritmici, meno intensi per l'allocazione della memoria sopra)
• Le chiamate al metodo Ruby sono lente (anche se, a causa della tipizzazione duck, sono probabilmente più veloci che nei linguaggi interpretati fortemente tipizzati)
• Ruby (ad eccezione di JRuby) non supporta il vero multithreading
• eccetera.

Ma, di nuovo, lento rispetto a cosa? Ruby 1.9 è più veloce di Python e PHP (con un fattore di prestazione 3x) rispetto a C (che può essere fino a 300x più veloce), quindi quanto sopra (ad eccezione delle considerazioni sul threading, se la tua applicazione dipendesse fortemente da questo aspetto ) sono in gran parte accademici.

Quali sono le tue opzioni come programmatore di Ruby se vuoi affrontare questa "lentezza"?

Scrivi per la scalabilità e lancia più hardware (ad es. Memoria)

Quale versione di Ruby si adatterebbe meglio ad un'applicazione come Stack Overflow in cui la velocità è critica e il traffico è intenso?

Bene, REE (combinato con Passenger ) sarebbe un ottimo candidato.

Ecco cosa ha da dire il creatore di Rails, David Heinemeier Hansson :

Rails [Ruby] è per la stragrande maggioranza delle applicazioni web Fast Enough. Abbiamo siti che effettuano milioni di visualizzazioni di pagina dinamiche al giorno. Se finisci per essere con la prima pagina di Yahoo o Amazon, è improbabile che un framework off-the-shelve in QUALSIASI lingua ti farà molto bene. Probabilmente dovrai farlo da solo. Ma certo, vorrei anche cicli di CPU gratuiti. Mi interessa solo molto di più sui cicli di sviluppo gratuiti e sono disposto a scambiare il primo con il secondo.

cioè lanciare più hardware o macchine al problema è più economico che assumere più sviluppatori e usare un linguaggio più veloce, ma più difficile da mantenere. Dopotutto, poche persone scrivono applicazioni web in C.

Ruby 1.9 è un grande miglioramento rispetto a 1.8. I maggiori problemi con Ruby 1.8 sono la sua natura interpretata (nessun bytecode, nessuna compilation) e che le chiamate di metodo, una delle operazioni più comuni in Ruby, sono particolarmente lente.

Non aiuta che praticamente tutto sia una ricerca del metodo in Ruby: aggiungere due numeri, indicizzare un array. Laddove altre lingue espongono hack ( __add__metodo di Python , overload di Perl. Pm) Ruby fa OO puro in tutti i casi, e questo può danneggiare le prestazioni se il compilatore / interprete non è abbastanza intelligente.

Se stavo scrivendo una popolare applicazione Web in Ruby, il mio focus sarebbe sulla cache. La memorizzazione nella cache di una pagina riduce a zero il tempo di elaborazione per quella pagina, qualunque sia la lingua in uso. Per le applicazioni Web, l'overhead del database e altri I / O iniziano ad avere molta più importanza della velocità della lingua, quindi mi concentrerei sull'ottimizzazione.

La scrittura del codice è lenta. La lettura del codice è lenta. Trovare e correggere i bug è lento. L'aggiunta di funzionalità e miglioramenti è lenta. Tutto ciò che migliora sul precedente è una vittoria. Molto raramente le prestazioni di esecuzione sono un problema.

La risposta è semplice: la gente dice che il rubino è lento perché è lento sulla base di confronti misurati con altre lingue. Tieni presente, tuttavia, che "lento" è relativo. Spesso, il rubino e altre lingue "lente" sono abbastanza veloci.

Joel on Software - Ruby Performance Revisited lo spiega abbastanza bene. Potrebbe essere obsoleto però ...

Consiglierei di attenersi a ciò come sei abituato a Ruby on Rails,
se mai dovessi incontrare un problema di prestazioni potresti riconsiderare l'uso di una lingua e un framework diversi.

In tal caso, suggerirei davvero C # con ASP.NET MVC 2 , funziona molto bene con le app CRUD.

Direi che Ruby è lento perché non sono stati fatti molti sforzi per rendere più veloce l'interprete. Lo stesso vale per Python. Smalltalk è dinamico come Ruby o Python ma offre prestazioni migliori in termini di grandezza, vedi http://benchmarksgame.alioth.debian.org . Poiché Smalltalk è stato più o meno sostituito da Java e C # (almeno 10 anni fa) non è stato fatto più alcun lavoro di ottimizzazione delle prestazioni e Smalltalk è ancora molto più veloce di Ruby e Python. Le persone di Xerox Parc e OTI / IBM avevano i soldi per pagare le persone che lavorano per rendere Smalltalk più veloce. Quello che non capisco è perché Google non spende i soldi per rendere Python più veloce in quanto sono un grande negozio Python. Invece spendono soldi per lo sviluppo di lingue come Go ...

Prima di tutto, ti interessa cosa dicono gli altri della lingua che ti piace? Quando fa il lavoro che deve fare, stai bene.

OO non è il modo più veloce per eseguire il codice, ma aiuta a creare il codice. Lo smart code è sempre più veloce del codice stupido e dei loop inutili. Sono un DBA e vedo molti di questi loop inutili, li trascino, uso codice e query migliori e l'applicazione è sempre più veloce. Ti interessa l'ultimo microsecondo? Potresti avere lingue ottimizzate per la velocità, altre semplicemente fanno il lavoro che devono fare e possono essere gestite da molti programmatori diversi.

È solo una scelta.

Ovviamente, parlando di velocità che Ruby perde. Anche se i test di benchmark suggeriscono che Ruby non è molto più lento di PHP. Ma in cambio stai ottenendo un codice DRY di facile manutenzione, il migliore tra tutti i framework in varie lingue.

Per un piccolo progetto, non avvertirai alcuna lentezza (intendo fino a quando <50.000 utenti) dato che nel codice non vengono utilizzati calcoli complessi, ma solo roba tradizionale.

Per un progetto più grande, pagare per le risorse paga ed è più economico dei salari degli sviluppatori. Inoltre, scrivere codice su RoR risulta essere molto più veloce di qualsiasi altro.

Nel 2014 questa grandezza della differenza di velocità di cui stai parlando è insignificante per la maggior parte dei siti web.

Il modo di gestire le prestazioni di Ruby nell'applicazione Web è lo stesso di qualsiasi altro linguaggio di programmazione:

ARCHITETTURA

Questo è più facile da fare in Rails che nella maggior parte degli altri Web Frame.

A livello di applicazione , memorizzando nella cache tutto ciò che si suppone debba essere memorizzato nella cache e gestendo l'accesso al DB in modo intelligente (poiché il collo di bottiglia si trova generalmente sull'accesso "DB" per la maggior parte delle app WEB).

Rails rende molto facile e naturale risolvere questi problemi. Esistono diverse astrazioni per la memorizzazione nella cache di dati, pagine e frammenti e ci sono anche astrazioni molto belle per gestire la parte SQL in modo ottimizzato e riutilizzabile ( Active Record e AREL ).

Questo è il motivo per cui così tante applicazioni scritte in linguaggi più rapidi e non così espressivi (come php) finiscono per essere più lente delle controparti Ruby. Non è così semplice ed elegante affrontare la memorizzazione nella cache e l'interrogazione con queste lingue di quanto non lo sia con Ruby.

A livello di infrastruttura è ragionevole pensare al bilanciamento del carico e a tutte quelle cose che non mi capitano di conoscere molto. Avrei esternalizzato quel problema assumendo una piattaforma come fornitore di servizi, come Heroku o Engine Yard . Comunque. La distribuzione di binari con bilanciamento del carico non è probabilmente molto difficile.

Ruby è più lento del C ++ in una serie di attività facilmente misurabili (ad esempio, fare codice che dipende fortemente dal virgola mobile). Questo non è molto sorprendente, ma una giustificazione sufficiente per alcune persone per dire che "Ruby è lento" senza qualifiche. Non contano il fatto che sia molto più semplice e sicuro scrivere il codice Ruby rispetto al C ++.

La soluzione migliore è utilizzare moduli mirati scritti in un'altra lingua (ad esempio, C, C ++, Fortran) nel tuo codice Ruby. Quelli possono fare il duro lavoro e i tuoi script possono concentrarsi su problemi di coordinamento di livello superiore.

Le prestazioni riguardano quasi sempre una buona progettazione e interazioni ottimizzate con il database. Ruby fa ciò di cui la maggior parte dei siti Web ha bisogno abbastanza velocemente, specialmente le versioni più recenti; e la velocità di sviluppo e la facilità di manutenzione offrono un grande vantaggio in termini di costi e di soddisfazione dei clienti. Trovo che JAVA abbia prestazioni di esecuzione lente per alcune attività e, data la difficoltà di sviluppo in JAVA, molti sviluppatori creano applicazioni lente indipendentemente dalla capacità di velocità teorica, come dimostrato nei benchmark (i benchmark sono generalmente concepiti per mostrare una capacità specifica e ristretta). Quando ho bisogno di un'elaborazione intensiva non adatta alle capacità del mio database, scelgo C o Objective-C o qualche altro linguaggio compilato ad alte prestazioni per quelle attività a seconda della piattaforma. Se devo creare un'applicazione Web basata su database, Uso RoR o talvolta C # ASP.NET a seconda di altri requisiti; perché tutte le piattaforme hanno punti di forza e di debolezza. La velocità di esecuzione delle cose che la tua applicazione fa è importante, ma dopo tutto, ciò che conta è l'esecuzione di un aspetto ristretto di una lingua; allora potrei ancora usare il linguaggio Assembler per tutto.

La gente dice che Ruby è lento perché confronta i programmi Ruby con i programmi scritti in altre lingue. Forse i programmi che scrivi non devono essere più veloci. Forse per i programmi che scrivi Ruby non è il collo di bottiglia che rallenta le cose.

Ruby 2.1 rispetto a Javascript V8

Ruby 2.1 rispetto al normale Lua

Ruby 2.1 rispetto a Python 3

Ruby si comporta bene per la produttività degli sviluppatori. Il rubino per natura forza lo sviluppo guidato dai test a causa della mancanza di tipi. Ruby funziona bene se usato come wrapper di alto livello per librerie C. Ruby si comporta bene anche durante i processi a esecuzione prolungata quando viene compilato JIT nel codice macchina tramite JVM o Rbx VM. Il rubino non funziona bene quando è necessario sbriciolare i numeri in breve tempo con un codice rubino puro.