Perché le applicazioni consumano tanta RAM? Come scoprirlo su Windows 11

Un’applicazione per la messaggistica istantanea può occupare oltre 1 GB di RAM su Windows, mentre un programma apparentemente più complesso utilizza poche decine di megabyte. La differenza non dipende soltanto dalle funzionalità: contano l’architettura software, i componenti caricati in memoria e il modo in cui il programma gestisce processi e risorse.

Un esempio arriva da Discord, che sta riscrivendo il client desktop in Rust, abbandonando Electron a favore di GPUI, un framework per interfacce grafiche native. Una versione sperimentale mostrata dagli sviluppatori occupa circa 290 MB di memoria, a dispetto delle risorse attualmente impegnato dall’applicazione che possono superare 1 GB di RAM.

Al di là dei singoli esempi, come possiamo stabilire se un programma consuma davvero troppa RAM? Windows 11 offre strumenti per misurare non soltanto la memoria occupata, ma anche il comportamento dei processi e l’effettivo impatto sulle prestazioni.

Electron, Tauri, WinUI 3 e applicazioni native: cosa cambia?

Electron consente di sviluppare applicazioni desktop utilizzando HTML, CSS e JavaScript. Il framework include Chromium e Node.js, adottando un’architettura multiprocesso: un processo principale gestisce l’applicazione, mentre altri si occupano delle interfacce, dei servizi e di attività specifiche.

Il vantaggio è la possibilità di condividere gran parte del codice tra Windows, Linux e macOS; lo svantaggio è il costo delle componenti necessarie per eseguire l’interfaccia web.

Tauri sceglie una strada diversa: utilizza Rust per la componente applicativa e il motore web già disponibile nel sistema operativo. Su Windows si appoggia a Microsoft Edge WebView2, evitando di distribuire un’intera copia di Chromium con ciascuna applicazione. Ciò può ridurre le dimensioni del pacchetto, senza eliminare il consumo di memoria del motore web. Abbiamo già visto un’applicazione sviluppata con Tauri nell’articolo dedicato a Mouzi, il programma per organizzare automaticamente la cartella Download.

WinUI 3 è invece il framework Microsoft per costruire interfacce Windows native con XAML e C# oppure C++: proprio Redmond ha deciso di spingere l’acceleratore su WinUI 3 e sulle app native mettendo fine alle critiche sulla strategia per l’interfaccia di Windows. WinUI 3 non richiede un browser per visualizzare i controlli, ma può dipendere dal runtime .NET e da ulteriori librerie.

Anche le applicazioni tradizionali Win32, sviluppate in C o C++, possono risultare molto efficienti. Tuttavia, nativo non significa automaticamente leggero: cache, framework, algoritmi inefficienti e gestione delle risorse possono incidere più della tecnologia scelta.

Come scoprire quale tecnologia utilizza un programma Windows

Come capire se un programma installato sul PC utilizza Electron, Tauri, WinUI 3 oppure un’interfaccia nativa tradizionale? Windows non mostra direttamente questa informazione, ma possiamo ricavare alcuni indizi dall’eseguibile, dalle librerie caricate e dai processi associati.

Apriamo Process Explorer (ne parliamo tra poco), individuiamo il programma e facciamo doppio clic sul processo principale. Nella scheda Image troviamo il percorso dell’eseguibile: aprendo la relativa cartella (pulsante Explore), possiamo cercare alcuni file caratteristici.

Le applicazioni Electron distribuite con le configurazioni più comuni contengono una directory resources con un archivio app.asar, utilizzato per raccogliere il codice applicativo. Possono inoltre includere librerie Chromium, come chrome_elf.dll. La presenza di questi file è un indizio significativo, anche se non tutte le applicazioni Electron sono distribuite nello stesso modo.

Per Tauri il riconoscimento è meno immediato. Su Windows il framework utilizza generalmente WebView2, quindi possiamo cercare eventuali processi msedgewebview2.exe associati al programma. La presenza di WebView2, tuttavia, non dimostra che l’applicazione sia sviluppata con Tauri: anche numerosi altri software utilizzano lo stesso componente Microsoft.

Nel caso di WinUI 3, possiamo selezionare il processo in Process Explorer, attivare View, Show Lower Pane e scegliere View, Lower Pane View, DLLs. La presenza della libreria Microsoft.UI.Xaml.dll suggerisce l’utilizzo di WinUI 3.

Il metodo più affidabile rimane incrociare gli indizi tecnici con la documentazione ufficiale del programma o con il relativo codice sorgente, quando disponibile.

I valori di utilizzo della RAM mostrati nel Task Manager non raccontano tutto

Premendo CTRL+MAIUSC+ESC e aprendo la scheda Processi, Windows mostra la memoria utilizzata dalle singole applicazioni. La sezione Dettagli permette di aggiungere ulteriori colonne, mentre Prestazioni, Memoria offre una panoramica dell’utilizzo complessivo della RAM, compresa la memoria disponibile e quella impegnata.

Bisogna comunque distinguere tre grandezze:

• Working Set: insieme delle pagine di memoria virtuale di un processo attualmente residenti nella RAM fisica, comprese quelle condivisibili.
• Private Working Set: parte del Working Set costituita da pagine private del processo.
• Private Bytes: memoria privata impegnata dal processo, che non deve necessariamente risiedere tutta nella RAM fisica.

Microsoft documenta le differenze nella pagina dedicata alle metriche di memoria dei processi Windows.

La distinzione è fondamentale: se due processi condividono determinate pagine fisiche, sommare i rispettivi Working Set può conteggiarle due volte. Allo stesso modo, Private Bytes non equivale alla quantità di RAM effettivamente occupata.

Come misurare il consumo di memoria con PowerShell

Windows 11 permette di effettuare una prima analisi senza installare programmi. Apriamo PowerShell ed eseguiamo:

Get-Process |
Sort-Object WorkingSet64 -Descending |
Select-Object -First 15 ProcessName, Id,
@{N="RAM_MB";E={[math]::Round($_.WorkingSet64/1MB,1)}},
@{N="Private_MB";E={[math]::Round($_.PrivateMemorySize64/1MB,1)}}

Il comando mostra i 15 processi con il Working Set più elevato, esprimendo in MB sia la memoria residente sia quella privata impegnata.

Un’applicazione – è importante sottolinearlo – può utilizzare numerosi processi: per ottenere un riepilogo di quelli denominati Discord, ad esempio, eseguiamo la seguente cmdlet:

Get-Process -Name "Discord*" |
Measure-Object WorkingSet64, PrivateMemorySize64 -Sum |
Select-Object Property,
@{N="Totale_MB";E={[math]::Round($_.Sum/1MB,1)}}

La somma dei Working Set fornisce soltanto una stima indicativa della RAM utilizzata da un’applicazione. Il motivo è che più processi possono utilizzare contemporaneamente le stesse pagine di memoria fisica, ad esempio quelle contenenti librerie DLL o altri componenti condivisi. Se due processi mostrano ciascuno un Working Set di 200 MB, ma condividono 80 MB di pagine residenti, la memoria complessiva effettivamente occupata è di 320 MB, non 400 MB.

C’è poi un altro problema: non tutti i processi appartenenti a un’applicazione hanno necessariamente lo stesso nome. Un programma sviluppato con Tauri, ad esempio, può utilizzare WebView2 per visualizzare la propria interfaccia. Il relativo motore web crea processi denominati msedgewebview2.exe, che non comparirebbero cercando soltanto il nome dell’applicazione principale. Inoltre, più applicazioni possono utilizzare WebView2, quindi non sarebbe corretto attribuire automaticamente tutti i processi con quel nome a un unico programma.

Per ottenere una misurazione più attendibile conviene utilizzare Process Explorer, che permette di esaminare la struttura dei processi e distinguere la memoria privata da quella potenzialmente condivisibile.

Process Explorer: distinguere memoria privata e condivisa

Per un’analisi più precisa, è possibile ricorrere a Process Explorer di Microsoft Sysinternals, scaricabile gratuitamente (download).

Avviamo l’utilità e selezioniamo View, Select Columns, Process Memory, abilitando le colonne Working Set Bytes, WS Private Bytes, WS Shareable Bytes e Private Bytes.

La visualizzazione ad albero permette inoltre di identificare processi figli e componenti ausiliari: per ogni applicazione osserviamo il numero dei processi, la quantità di memoria privata e la variazione dei valori durante l’utilizzo.

Una crescita continua di Private Bytes dopo operazioni ripetute merita attenzione, soprattutto se la memoria non diminuisce dopo la chiusura dei documenti o delle finestre. Non dimostra però, da sola, una perdita di memoria (memory leak): potrebbe dipendere da cache intenzionali o allocatori che conservano memoria per riutilizzarla.

RAMMap: dove finisce la memoria fisica?

Per completare l’analisi possiamo utilizzare anche RAMMap, un’altra utilità Microsoft Sysinternals di cui abbiamo già illustrato il funzionamento. Mentre Process Explorer permette di studiare i singoli processi, RAMMap mostra come Windows distribuisce la memoria fisica tra applicazioni, cache, file mappati, kernel e driver.

Nella scheda Use Counts possiamo distinguere la memoria Active, attualmente utilizzata, dalla memoria Standby, conservata come cache ma recuperabile quando necessario.

La scheda Processes permette invece di esaminare la composizione dei Working Set. È un controllo utile per capire se la RAM apparentemente occupata rappresenti una reale pressione sulla memoria oppure sia in gran parte utilizzata per accelerare le operazioni del sistema.

Come fare analisi e confronti: 5 misure da verificare

Per confrontare due applicazioni, si può svolgere una prova pratica: stesso PC, medesime condizioni di alimentazione, aggiornamenti completati e altre applicazioni non necessarie chiuse. Riavviamo il programma e ripetiamo almeno 3 volte queste misurazioni:

1. Memoria a riposo: rileviamo Working Set e Private Bytes dopo 60 secondi dall’avvio.
2. Carico reale: ripetiamo la misura dopo 5 minuti di utilizzo, eseguendo operazioni equivalenti.
3. CPU: osserviamo l’utilizzo durante le operazioni e quando l’applicazione è inattiva.
4. Avvio: misuriamo con un cronometro il tempo necessario affinché l’interfaccia diventi utilizzabile, distinguendo avvio a freddo e successivi avvii.
5. Dimensioni: confrontiamo installazione e pacchetto distribuito, annotando separatamente eventuali runtime condivisi.

È importante registrare anche il numero di processi e, nella scheda Prestazioni, Memoria del Task Manager, verificare memoria disponibile e memoria impegnata complessiva.

Quando due programmi utilizzano componenti differenti, il confronto deve comprendere soltanto attività funzionalmente equivalenti. Un editor con dieci documenti aperti non può essere confrontato con uno appena avviato.

Quando un’applicazione consuma davvero troppa RAM?

Non esiste una soglia universale. Un programma che occupa 900 MB su un computer con 32 GB di RAM può non creare alcun problema; lo stesso consumo diventa più significativo su una macchina con 8 GB e numerosi processi attivi.

I segnali da considerare sono la progressiva riduzione della memoria disponibile, l’aumento dei page fault che richiedono accessi al disco, i rallentamenti nel passaggio tra applicazioni e un utilizzo anomalo della CPU anche a riposo.

Se un’applicazione presenta consumi elevati soltanto durante operazioni complesse, il comportamento può essere giustificato. Se invece continua ad accumulare memoria senza svolgere attività, è opportuno passare al controllo di aggiornamenti, estensioni, processi in background ed eventuali problemi noti.

La scelta tra Electron, Tauri, WinUI 3 e codice nativo influenza i “costi di base” dell’applicazione, ma la misura decisiva resta il comportamento effettivo del programma.