indietro

Il massimo è trovare un algoritmo migliore. Spesso la differenza è notevole. Potreste controllare il capitolo 8 del Camel Book, che contiene alcuni trucchi per migliorare l'efficienza. Anche il libro di Jon Bentley, "Programming Pearls" (non è un errore di battitura!), contiene buoni suggerimenti sull'ottimizzazione. Per quanto riguarda i benchmark, il consiglio si riassume in: realizzate dei benchmark e fate profiling per essere sicuri di ottimizzare nel punto giusto, cercate degli algoritmi migliori anziché mettere a punto i dettagli, e quando tutti i tentativi falliscono, considerate la possibilità di comprare hardware più veloce. Potreste voler leggere la risposta alla precedente domanda "Come effettuo il profiling dei miei programmi Perl?" se non l'avete già fatto.

Un approccio diverso consiste nell'applicare le tecniche di Autoloading al codice utilizzato di rado. Guardate i moduli AutoSplit e AutoLoad nella distribuzione standard. Oppure potete capire qual è il collo di bottiglia e scrivere solo quella parte in C, così, come si usava individuare i colli di bottiglia nel codice C per poi riscriverli in assembler. Analogo alla riscrittura del codice in C è l'uso di moduli nei quali le sezioni critiche sono scritte in C (ad esempio, il modulo PDL di CPAN).

Se al momento il vostro eseguibile perl è linkato ad una libc.so condivisa, allora in molti casi potete ottenere un miglioramento della performance del 10-25% ricompilandolo e linkandolo ad una libc.a statica. Questo produrrà un eseguibile perl più grande, ma i vostri programmi (e i programmatori) vi ringrazieranno. Guardate il file INSTALL nella distribuzione del codice per ulteriori informazioni.

Il programma undump era un vecchio tentativo di velocizzare i programmi Perl memorizzandoli su disco in forma già compilata. Non è più un'opzione praticabile, dato che funziona solo su alcune architetture, e comunque non era una buona soluzione.

vedi in inglese