|
I° Benchmark: ciclo senza nessun errore da rilevare
| Pos |
Ripetizioni |
Tempo Condizioni |
Tempo Eccezioni |
Cond / Eccez |
| 1 |
10.000.000 |
125 |
45 |
2,78 |
| 2 |
100.000.000 |
1.220 |
420 |
2,90 |
| 3 |
1.000.000.000 |
12.155 |
4.280 |
2,84 |
| 4 |
2.000.000.000 |
24.435 |
8.560 |
2,85 |
Tempo espresso in millisecondi. |
|
II° Benchmark: un errore per ogni ripetizione del ciclo
| Pos |
Ripetizioni |
Tempo Condizioni |
Tempo Eccezioni |
Eccez / Cond |
| 1 |
1.000 |
0 |
80 |
|
| 2 |
10.000 |
0 |
830 |
|
| 3 |
100.000 |
1 |
8.300 |
8.300 |
| 4 |
200.000 |
2 |
16.900 |
8.450 |
| 5 |
1.000.000 |
12 |
83.200 |
6.933 |
Tempo espresso in millisecondi. |
| Conclusioni
Risultati:
-
Se non ci sono errori da rilevare, le eccezioni risultano quasi tre volte più veloci (2,8);
-
Se gli errori da rilevare sono la maggior parte dei casi, la gestione delle eccezioni risulta essere circa ottomila volte più lenta!
Facciamoci la seguente domanda:
Conviene utilizzare la gestione delle eccezioni oppure conviene controllare il valore di ritorno di un metodo?
-
Se si deve controllare la possibile condizioni di errore di una funzione che impiega pochi cicli di clock e che non è in profondità in delle chiamate nidificate, conviene controllare il valore di ritorno del metodo. All'interno del metodo conviene inserire delle condizioni (if) che controllano la validità dei dati.
-
Nel caso in cui, l'errore dipenda da un qualcosa difficilmente controllabile e che non è inserito in un ciclo che viene ripetuto un numero elevato di volte, conviene utilizzare le eccezioni, sia per la chiarezza che per l'affidabilità |
Print | posted @ lunedì 15 gennaio 2007 02:41