CPU o memoria elevati di Cursor su Mac: individuare il lavoro che occupa risorse

Cursor può rendere un Mac lento per diversi motivi: un'estensione occupata, un workspace di grandi dimensioni in elaborazione, un'attività AI di lunga durata o un processo che continua a consumare memoria dopo la fine del lavoro. Inizia individuando quale azione provoca l'aumento. Una cartella cache di grandi dimensioni non è prova che cancellarla risolverà l'uso della CPU.

Mantieni un confronto riproducibile

Salva il progetto e annota la versione di Cursor. Apri Monitoraggio Attività, cerca Cursor e confronta CPU e memoria prima di aprire il progetto, durante la riproduzione del problema e dopo l'arresto dell'attività. Mantieni lo stesso repository e la stessa azione per ogni test.

Se una cartella piccola si comporta normalmente ma un monorepo no, l'ambito del workspace è un indizio utile. Se una nuova chat risponde mentre una conversazione lunga no, verifica quel caso separatamente. Se l'uso cresce costantemente sotto un carico ripetuto, registra la crescita e il tempo trascorso. Una sola lettura elevata non basta a stabilire una perdita di memoria.

Separare l'editor dal lavoro che avvia

Una sessione di Cursor può includere la finestra dell'editor, le estensioni, un language server, i terminali e un'attività AI. Parte di quel lavoro può continuare mentre l'editor è inattivo. Prima di disattivare qualcosa, verifica se un terminale sta ancora eseguendo una build, un watcher di test, un server di sviluppo o un modello. Interrompi solo un processo che riconosci, tramite il normale controllo del terminale o dell'applicazione, dopo aver salvato il suo lavoro.

In Monitoraggio Attività, confronta il processo impegnato in tre momenti: con il workspace aperto ma nessuna attività avviata, durante l'azione che sembra lenta e dopo che quell'azione è terminata. Annota il nome del processo e se il sintomo è un ritardo nell'input, un uso elevato della CPU o una memoria in aumento. Il nome di un processo helper da solo raramente identifica l'estensione responsabile, quindi usa i confronti successivi per restringere il campo.

Prova ad aprire la cartella effettiva del progetto invece della sua cartella superiore che contiene più repository. Non spostare né eliminare il progetto per eseguire questo test. Se un workspace più piccolo migliora il risultato, determina cosa includeva il workspace più ampio: asset generati, dipendenze di un altro progetto, un watcher attivo o uno strumento linguistico che analizza più file. Questa è una prova sull'ambito, non un motivo per escludere ogni cartella di grandi dimensioni.

Per esempio, un server di sviluppo che scrive output ripetutamente può essere un lavoro attivo che l'editor osserva. L'esclusione di una cartella e l'arresto di quel server verificano spiegazioni diverse. Modificando entrambe le cose contemporaneamente si perde la distinzione, quindi annota quale singola modifica influisce sull'azione ripetuta.

Verifica le estensioni prima di reimpostare l'editor

La guida alle prestazioni di Cursor consiglia un avvio con le estensioni disabilitate. Dopo aver salvato il lavoro e chiuso Cursor normalmente, avvialo dal Terminale con:

cursor --disable-extensions

Questo presuppone che il comando di shell cursor sia installato. Se non è disponibile, usa la vista Estensioni di Cursor per disabilitare le estensioni non essenziali ai fini del confronto. Tieni un registro di ciò che hai disabilitato, così il test è reversibile.

Ripeti la stessa azione sul progetto. Se migliora, ripristina le estensioni una alla volta finché il sintomo ricompare. Se non migliora, ripristina lo stato precedente delle estensioni e continua. Non considerare un test con file aperti diversi come prova contro un'estensione e non rimuovere l'intera directory dei dati utente come passo successivo.

Restringere un test delle estensioni riuscito

Se l'esecuzione con le estensioni disattivate migliora la stessa azione, non reinstallare tutte le estensioni né scartare le loro impostazioni. Parti dall'insieme registrato di estensioni attive e ripristinale una alla volta quando ci sono solo pochi candidati. Con molte estensioni, ripristinarne metà alla volta può restringere il gruppo più rapidamente, a condizione che ogni test apra lo stesso progetto e completi la stessa azione.

Il metodo a gruppi è una scorciatoia investigativa, non la prova che ci sia esattamente un'estensione difettosa. Due estensioni possono interagire, e disattivare un'estensione linguistica può anche rimuovere funzionalità che attivano il carico di lavoro. Una volta emerso un candidato, ripeti il test con tutte le estensioni di cui hai effettivamente bisogno attive tranne quel candidato. Verifica il completamento del codice, la diagnostica e la build oltre alla reattività.

Se il confronto finale indica ancora un'estensione, annota il suo nome e la versione. Disattivarla solo nel workspace può essere più adatto che modificare ogni progetto, dove quell'opzione esiste. Se disattivarla rompe una funzionalità necessaria, ripristinala e conserva la riproduzione per chi la mantiene, invece di considerare un editor più veloce ma incompleto come il risultato desiderato.

Escludi l'output generato di cui non hai bisogno

Il lavoro assistito dall'AI può produrre output di build, bundle esportati, immagini generate e log di grandi dimensioni. Aprire una cartella padre che contiene tutti i progetti può esporre molto più materiale di quanto l'attività richieda. Apri prima la radice effettiva del progetto.

Cursor documenta .cursorignore per limitare l'accesso dell'AI ai file del progetto, con eccezioni per i terminali e gli strumenti MCP. La sua guida alle prestazioni consiglia di escludere le cartelle generate di grandi dimensioni. Questo è più ampio di una modifica limitata all'indicizzazione e non arresta ogni language server o filesystem watcher.

Per un progetto in cui queste directory sono davvero output generato, un file .cursorignore può contenere:

dist/
build/
.next/

Ispeziona prima le cartelle e preserva le regole di esclusione esistenti. Una directory chiamata build potrebbe contenere script di build mantenuti manualmente nel tuo progetto. Aggiungere un pattern non elimina file, ma può rimuovere contesto utile dalle funzionalità AI. Ricontrolla lo stato dell'indicizzazione e la stessa azione dell'editor in seguito.

Segui il processo che funziona ancora

La guida alla pressione memoria su Mac spiega perché la memoria usata da sola non è un allarme affidabile. Chiudere un workspace inutilizzato può aiutare un carico attivo senza eliminarne il contenuto.

Verificare cosa ha cambiato un'esclusione

Dopo aver modificato .cursorignore, esamina il diff del file e prova sia l'azione lenta sia una domanda ordinaria su codice che dovrebbe restare accessibile. Un contesto del progetto visibile più ridotto è utile solo se Cursor ha ancora il codice sorgente necessario per l'attività. Rimuovi solo il nuovo pattern se ha escluso qualcosa di importante; non sostituire l'intero file ignore con uno vuoto.

Tieni separati questi confini. Le regole di Git ignore governano il trattamento da parte di Git dei file non tracciati. Le esclusioni di accesso AI di Cursor governano le funzionalità AI documentate. Un language server, un'estensione o un watcher di terminale ha un proprio comportamento. Aggiungere lo stesso pattern ovunque senza identificare il componente impegnato può nascondere i sintomi e rimuovere funzionalità utili.

Se la CPU è normale ma una risposta tarda ad arrivare, indaga la richiesta AI separatamente dall'uso delle risorse dell'editor. Se la memoria aumenta a ogni ripetizione anche dopo che il lavoro è terminato, annota diverse letture comparabili e gli intervalli trascorsi, poi verifica se riaprire il workspace cambia il comportamento. Questo è molto più utile per chi mantiene il software rispetto a segnalare il valore più alto visto durante una build.

Pulisci i residui su disco solo quando il problema è lo spazio

Le cache di Cursor, le vecchie versioni degli strumenti, le cronologie delle sessioni e i worktree hanno proprietari e necessità di recupero diversi. Un worktree può contenere modifiche non committate o un commit che non esiste altrove. Una cronologia chat può essere lavoro di cui hai ancora bisogno.

Usa la guida alla pulizia degli strumenti di coding AI per quel compito di archiviazione separato. Per problemi persistenti di CPU o memoria, invia a Cursor il caso riproducibile più piccolo, la versione e il confronto delle estensioni. Controlla i log prima di condividerli, perché possono contenere nomi di progetti o codice. Così la segnalazione riguarda il rallentamento reale e non il risultato di una pulizia non correlata.