Ormai anche i sassi sanno che una delle importanti feature che sono introdotte dal framework .NET 2.0 sono gli Iterators. GLi iterators sono in soldoni un modo alternativo agli enumeratori per iterare, appunto, all'interno di collections, o più genericamente di insiemi. Ma la potenza che viene messa in campo dagli Iterators è talmente elevata, che già da un po' si possono trovare nella rete degli esempi molto belli nei quali essi sono usati anche in modi un po' più creativo, ad esempio come generatori di numeri primi, oppure come iteratori del filesystem.

Questo ultimo caso, che si potrebbe riassumere nel traversare ricorsivamente un albero, in realtà rivela dei problemi che se trascurati potrebbero avere un impatto enorme sulle performance del codice, ma soprattutto sull'utilizzo delle risorse da parte di quest'ultimo. Infatti, come ogni algoritmo ricorsivo, anche quello che viene generato con gli Iterators ha la tendenza ad impegnare una grande quantità di memoria, e quindi merita di essere usato solo per ricorsioni poco profonde. In particolare, l'uso ricorsivo degli iterators ha la caratteristica di generare un enorme lavoro per il Garbage Collector.

Invece che portare un esempio di quanto sto dicendo, propongo la lettura attenta di questo post, che da una dimostrazione molto efficace del problema, ma che inoltre si preoccupa di dare una altrettanto efficace indicazione di come affrontare questo genere di algoritmi, rimanendo sempre nell'ambito degli Iterators.

L'esempio finale di elaborazione mediante Iterators del problema delle Torri di Hanoi, è in grado grazie ad un accorto uso di uno stack, di portare il tempo di esecuzione dai 20 secondi dell'algoritmo ricorsivo a meno di 1 secondo. Vale la pena di investire un po' di tempo nel leggerlo.