Capita alle volte che i programmatori non abbiano a che fare con la soluzione di problemi algoritmici, ma che debbano risolvere problemi legati all’uso della memoria dell’applicazione.
Certo è sempre un problema di come viene scritto il codice, ma rispetto ad un errore algoritmico che si mostra immediatamente (alle volte anche all’utente finale) un errore di gestione della memoria si fa vedere solo ad un certo punto, quando le cose sono degradate troppo e il server ha finito la memoria disponibile. Un effetto che può risultare anche molto lontano dalla causa.
In questi casi dobbiamo dare risposta alla domanda “ma dov’è che ho messo tutta questa memoria?”. Oggi scrivo questo post per dare un paio di consigli apparentemente semplici ma che ho notato essere utili.
Come prima cosa è bene utilizzare uno strumento efficace per l’analisi, non affidatevi semplicemente a quello che vi dice Task Manager perché non è uno strumento pensato per questo scopo. Task Manager vi informa semplicemente del fatto che una certa applicazione sta usando un certo quantitativo di memoria del sistema operativo, ma non vi dice in quali classi è usata e soprattutto non fa distinzione tra memoria effettivamente usata dell’applicazione e quella che il server web tiene per sé perché sa di poterne avere bisogno.
Per fare una prova con questo piccolo progetto di esempio su IIS e capire di che tipo di strumento sto parlando, vi consiglio di provare la demo di ANTS Memory Profiler, che ho trovato davvero efficace e di aiuto in un compito complesso come la soluzione di un memory leak.
Provate ad aprire la videatea New Form IMDB e a controllare in quali classi viene usata la memoria, troverete live instance di IMDBFldValue che corrispondono alle 30.000 righe che ho inserito in una tabella IMDB (le In Memory Database di Instant Developer).
Provate a chiudere la videata e a ricontrollare la memoria, avrete sempre lo stesso numero di istanze di IMDBFldValue ancora “vive” in memoria. Succede perché le tabelle IMDB sono fatte apposta per essere accessibili da tutta l’applicazione, da questo punto di vista sono da considerare al pari di una variabile globale. Alla chiusura della videata New Form IMDB la tabella IMDB contenuta all’interno non viene quindi svuotata ma tenuta in memoria per l’eventuale riutilizzo da parte di altre procedure dell’applicazione.
Ed è qui che entra in ballo il secondo consiglio, rivolto a chi utilizza Instant Developer. E’ prassi comune svuotare le tabelle IMDB subito prima di riempirle, tipicamente questo accade quando si apre la videata, ma se usate IMDB di grandi dimensioni potreste incorrere in problemi di memoria se non svuotate le tabelle anche alla chiusura della form usando l’evento di Unload.
Provate a scommentare il contenuto dell’evento nel progetto e vedrete subito la differenza.