# Migliorare le performance di Radius

**URL:** <https://www.ruby-forum.com/t/migliorare-le-performance-di-radius/186170>\
**Category:** IT\
**Created:** [April 1, 2010, 4:03pm UTC](https://www.ruby-forum.com/t/migliorare-le-performance-di-radius/186170 "2010-04-01T16:03:20Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![sistrall](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/65b543/32.png) [@sistrall](https://www.ruby-forum.com/u/sistrall)\
**Post date:** [April 1, 2010, 4:03pm UTC](https://www.ruby-forum.com/t/migliorare-le-performance-di-radius/186170/1 "2010-04-01T16:03:20Z")

</div>

Ciao a tutti,

sono a caccia di consigli. 🙂

Ho un’applicazione in cui uso la gemma Radius [1](http://github.com/jlong/radius) per produrre  
documenti Word e Excel XML.  
La gemma è comoda (definire i tag è un gioco da ragazzi) e produrre  
documenti anche più facile.

La parte più complicata è farlo con performance ragionevoli.

Tutto va bene se si tratta di produrre documenti relativi a pochi  
dati. Ma quando tento di produrre, per fare un esempio, un file Excel  
che elenca dati tratti da un migliaio di record i tempi diventano  
inaccettabili: nell’ordine dei minuti.

Qualcuno di voi ha mai usato Radius? Che strada tentereste per  
migliorare la situazione? Radius fa largo uso di regexp e lavora  
pesantemente su stringhe: mi viene da ipotizzare che Ruby 1.9 (ora  
sono in produzione su 1.8.7) potrebbe dare vantaggi, ma quanto  
tangibili?

Intanto grazie,  
Silvano

Links:

–  
Considera l’ambiente prima di stampare questa email. Be a total user  
rather than a complete waster.

. . . Silvano S. . . .  
email: removed\_email\_address@domain.invalid  
site: [http://www.sistrall.it](http://www.sistrall.it)

---

<div class="post-metadata">

**Author:** ![sistrall](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/65b543/32.png) [@sistrall](https://www.ruby-forum.com/u/sistrall)\
**Post date:** [April 2, 2010, 10:53am UTC](https://www.ruby-forum.com/t/migliorare-le-performance-di-radius/186170/2 "2010-04-02T10:53:33Z")

</div>

Silvano S. wrote:

> Tutto va bene se si tratta di produrre documenti relativi a pochi  
> dati. Ma quando tento di produrre, per fare un esempio, un file Excel  
> che elenca dati tratti da un migliaio di record i tempi diventano  
> inaccettabili: nell’ordine dei minuti.
> 
> Qualcuno di voi ha mai usato Radius? Che strada tentereste per  
> migliorare la situazione? Radius fa largo uso di regexp e lavora  
> pesantemente su stringhe: mi viene da ipotizzare che Ruby 1.9 (ora  
> sono in produzione su 1.8.7) potrebbe dare vantaggi, ma quanto  
> tangibili?

Ciao, i tuoi problemi sono 3:  
ottimizzazione concatenamento stringhe :  
‘abcd’ + ‘cde’ + ‘fgw’  
“abcd” + “cde” + “fgw”  
“abcd” \<\< “cde” \<\< “fgw”  
“#{”abcd”}#{”cde”}{”fgw”}”  
L’ordine indica la velocità di esecuzione il 4 è il più veloce.

numero di query sql: cerca di ottimizzare il numero di query, magari  
craz una view così velocizzi

scrittura file: se il file che generi è grosso la scrittura su disco  
diventa un grosso collo di bottiglia, quindi se salvi il file valuta se  
non sia meglio inviare direttamente la stringa al client

---

<div class="post-metadata">

**Author:** ![sistrall](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/65b543/32.png) [@sistrall](https://www.ruby-forum.com/u/sistrall)\
**Post date:** [April 2, 2010, 12:54pm UTC](https://www.ruby-forum.com/t/migliorare-le-performance-di-radius/186170/3 "2010-04-02T12:54:05Z")

</div>

Grazie Alessandro,

On Friday, April 2, 2010, Alessandro S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> > tangibili?
> 
> Ciao, i tuoi problemi sono 3:  
> ottimizzazione concatenamento stringhe :  
> ‘abcd’ + ‘cde’ + ‘fgw’  
> “abcd” + “cde” + “fgw”  
> “abcd” \<\< “cde” \<\< “fgw”  
> “#{”abcd”}#{”cde”}{”fgw”}”  
> L’ordine indica la velocità di esecuzione il 4 è il più veloce.

Ecco: credo che questo sia il punto dolente. Proverò a lavorarci.

> numero di query sql: cerca di ottimizzare il numero di query, magari  
> craz una view così velocizzi

Il tempo richiesto dalle operazioni su db è quasi ininfluente: 2  
secondi su 2 minuti.

> scrittura file: se il file che generi è grosso la scrittura su disco  
> diventa un grosso collo di bottiglia, quindi se salvi il file valuta se  
> non sia meglio inviare direttamente la stringa al client

Questo è un altro punto interessante: i file prodotti non sono  
immensi, ma arrivano facilmente al mezzo mega.

Grazie mille per i consigli. Ci lavoro.  
Silvano

–  
Considera l’ambiente prima di stampare questa email. Be a total user  
rather than a complete waster.

. . . Silvano S. . . .  
email: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
site: [http://www.sistrall.it](http://www.sistrall.it)