Originariamente inviato da hwplanet
Ho il problema che il software fa un uso smisurato della memoria; basta avviare il programma (che all'avvio è solo 1 form con un banale menù per avviare gli altri form) e già son 12Mb utilizzati, se apro il form per gestire la rubrica (una tabella con circa 30 campi), gestita mediante table adapter creato col wizard, l’occupazione di memoria schizza a 25Mb, e la cosa assurda è che in tabella ci ho messo giusto un paio di record tanto per testare il funzionamento! Va da sé che se poi apro anche altri form l’uso della memoria continua ad aumentare in maniera esponenziale; immagino che il problema stia nel fatto che i dati son caricati tutti in memoria, anche se non riesco a capire come 3 record possan occupare 25Mb!!!
Welcome to the .NET world!

Lavorando con un "ambiente gestito" quale è quello offerto dal CLR di .NET, non è possibile aspettarsi sempre un comportamento lineare in termini di fattori occupazionali e prestazionali dell'applicazione, poiché questi aspetti dipendono da molteplici fattori su cui il programmatore non ha una diretta influenza e che, a seconda dello stato del sistema, possono variare.

Quando il CLR esegue codice, controlla la quantità di memoria disponibile e può, all'occorrenza, allocarne più di quanto non sia strettamente necessario poiché le condizioni del sistema lo consentono e questo può eventualmente favorire prestazioni più elevate in seguito; oppure ancora, il CLR potrebbe rilevare una particolare CPU e ottimizzare il codice nativo generato per eseguire più celermente su quella architettura.

Quando invece le risorse sono scarse, il CLR può optare per una conformazione più conservativa rispetto alle risorse del sistema.

Nel caso della velocità, è possibile che a diverse esecuzioni si abbiano tempi differenti per lo stesso processo; può accadere infatti che, nell'eseguire una determinata operazione magari anche lunga, il CLR intervenga rilasciando la memoria per gli oggetti che sono stati sottoposti a Garbage Collection, oppure questo rilascio più essere dilazionato nel tempo per diversi motivi che fanno capo all'architettura interna dello stesso runtime.

Originariamente inviato da hwplanet
Inoltre, chiudendo il form la memoria non viene comunque scaricata
Chiudere il form non significa distruggere l'oggetto: è un'operazione che viene avviata solamente tramite il Garbage Collector quando non vi sono più riferimenti validi ad un determinato oggetto.

Originariamente inviato da hwplanet
ho provato a usare il sia il comando clear che dispose per il dataset, senza risultato.
Anche eseguendo Dispose, tutto ciò che viene rilasciato sono le risorse non gestite dal framework (ad esempio, le risorse native, i canali di I/O aperti su file o su socket, ecc.) ma non gli oggetti stessi che, come descritto prima, sono assoggettati al volere del Garbage Collector.

Originariamente inviato da hwplanet
Avevo anche provato a gestire inserimenti e visualizzazioni da codice con comandi sql anziché usare i tool visuali, ma aldilà del maggior tempo di programmazione ottenevo che si occupava meno memoria ma quando c’era da far un insert o una select i tempi eran biblici (almeno usando i dataset ci mette di più a caricare ma una volta che son in memoria si procede ragionevolmente spediti)
In questo frangente, controllerei che non siano presenti problemi nella connessione al DB e verificherei l'ottimizzazione dello stesso. Non ho mai avuto grossi problemi prestazionali con le classi per l'accesso ai dati. Quale famiglia di classi ADO.NET usi per il collegamento?

Originariamente inviato da hwplanet
Come faccio a ridurre drasticamente il consumo di memoria e ottenere contemporaneamente una buona velocità di esecuzione del programma? Può aiutare creare più dataset anziché uno unico che contiene i table adapter per tutte le tabelle?
Rispondo dicendo solamente che se ti aspetti di vedere scendere l'occupazione di RAM a pochi Kb, puoi già scordartelo in quanto generalmente qualsiasi applicazione Windows Forms ha un limite inferiore che difficilmente si può abbassare senza "salti mortali".

Del resto, bisogna tenere conto del fatto che il CLR è un elemento attivo che svolge determinati servizi, pertanto occorre che vi sia posto in memoria anche per il codice che lo costituisce affinché l'applicazione possa beneficiarne per svolgere il proprio compito.

Ciao!