Ruby  »  Articoli  »  Rails 

Il fulcro di questo articolo sottende molti e variegati aspetti del mondo Rails e, inevitabilmente, di Ruby; affronteremo quindi il tutto in capitoli ben distinti che possano evidenziare le problematiche di Ruby e di Rails in termini di performance, suggerendo al contempo alcuni trucchi per ottimizzare la stesura del proprio applicativo.

Ruby è lento?

La risposta lapidaria dovrebbe essere: SI. Fin dalla nascita la Virtual Machine Ufficiale (detta anche MRI (Matz's Ruby Interpreter) non ha mai spiccato né per performance, né per gestione della memoria; esistono però alcune regole che, se seguite, possono garantirci un certo miglioramento nelle prestazioni.

Limitare le ricerche nell'Abstract Syntax Tree

A differenza di molti altri linguaggi interpretati, Ruby 1.8.6 non traduce il codice in bytecode prima di eseguirlo ma si appoggia solamente ad un Abstract Syntax Tree nel quale è memorizzata l'intera struttura del programma in esecuzione.

Per ogni chiamata ad ogni entità dell'applicazione (metodo, variabile, etc.) l'interprete deve dunque navigare l'AST effettuando così un operazione sufficientemente costosa.

Si può scrivere codice che limiti il numero di ricerche nell'AST? Si, ad esempio facendo uso delle variabili di istanza; Ruby infatti utilizza una cache per questo tipo di elementi che quindi risultano più performanti rispetto alla loro versione classica:

@var1 = "Hello to everybody"
puts @var1     # in questo caso Ruby cerca prima nella sua cache
puts self.var1 # in questo caso invece và sempre nell'AST

Nelle stringhe, inclusione al posto della concatenazione

Chris Blackburn ha dimostrato come sia più efficiente utilizzare il marcatore di inclusione #{} all'interno di stringhe tra doppi apici che concatenare tra loro stringhe con il metodo '<<'.

str = "questa #{var1} verrà composta velocemente"
str = 'questa invece è più lenta ' << var2

Il motivo di questa differenza di performance tra le due implementazioni (la prima è due volte più veloce della seconda) è da ricercarsi nella strutturazione del codice sorgente della MRI che, sintetizzando, effettua una singola chiamata a funzione nel primo caso e almeno due nel secondo.

Utilizzare, dove possibile, operazioni distruttive

La maggior parte dei metodi di elaborazione disponibili sugli oggetti più utilizzati in Ruby sono proposti in due versioni, quella classica (es: gsub) e quella distruttiva (es: gsub!). La differenza principale tra queste due diverse implementazioni consiste nel fatto che la seconda effettua l'operazione voluta direttamente sull'oggetto invocante mentre la prima restituisce una copia dell'oggetto modificata secondo il metodo chiamato.

Altri articoli

Altre guide

Altre newsletter