Misurare le prestazioni reali di un laptop è possibile, ma serve metodo. Un singolo punteggio non basta: vanno standardizzati profili energetici, carichi di lavoro e logging per evitare bias e letture fuorvianti. Con una procedura replicabile, ogni risultato diventa confrontabile nel tempo e tra macchine diverse.
Questa guida sintetizza un percorso pratico per testare CPU, GPU, SSD e autonomia senza cadere nelle trappole più comuni: thermal throttling ignorato, cache dell’SSD che altera i numeri, script non controllati, outlier presi per oro colato.
Preparazione: profili energetici, ambiente e variabili di test
Prima di qualsiasi run, definire un profilo energetico coerente. Su Windows: disattivare sospensione, impostare “Prestazioni elevate” o “Massime prestazioni”, bloccare la frequenza minima al 100% solo quando il test lo richiede e disattivare risparmi energetici aggressivi su USB/Wi-Fi. Su Linux: usare TLP o power-profiles-daemon con profilo performance; verificare governor performance. Annotare versione BIOS/UEFI, driver GPU, sistema operativo e patch.
Stabilizzare l’ambiente: temperatura ambiente 21 ± 2 °C, piano d’appoggio rigido, nessuna base di raffreddamento se non dichiarata. Disattivare sincronizzazioni cloud, antivirus in scansione, indicizzazione e update. Impostare luminosità schermo al 200 nit (misurata o stimata, tipicamente 60–80%) e volume al 50% quando rilevante. Ogni deroga va loggata in un file di configurazione del run.
CPU: carichi riproducibili e controllo del thermal throttling
Per la CPU servono carichi coerenti e ripetibili. Consigliati: Cinebench R23/R24 multi/single core, 7-Zip benchmark (dizionario e thread fissi), Blender Benchmark con scene Classroom/Monster/Junkshop e HandBrake con transcodifica H.264/H.265 su clip open (Tears of Steel 4K, Sintel 1080p). Eseguire 5 run, scartare warm-up, riportare mediana e intervallo interquartile.
Monitorare frequenze, temperature e potenza (CPU Package Power) con HWiNFO (Windows) o lm-sensors/perf (Linux). Il thermal throttling va documentato: picchi di temperatura seguiti da cali di frequenza indicano un limite termico o di TDP. Per confronto equo, aggiungere un run “limitato” a 28 W/45 W se il produttore dichiara PL specifici, e un run “massime prestazioni” su rete elettrica.
GPU: sintetici, workload reali e logging rigoroso
La GPU si testa con mix di sintetici e scenari reali. Per sintetici: 3DMark (Time Spy/Fire Strike), Unigine Superposition a preset 1080p/4K. Per workload reali: Blender (CUDA/OptiX/Metal), giochi con benchmark integrato coerente (ad es. 1080p medio/alto, V-Sync off) e ffmpeg NVENC/AMF/Quick Sync per encoding.
Registrare frame time, utilizzo GPU, frequenza e limiti termici con PresentMon/CapFrameX o nvidia-smi/radeontop. Ripetere 3–5 run, riportare media, mediana e 1% low. Se i frame time mostrano stutter periodico, controllare il power plan o il driver scheduling. Documentare se è attiva la modalità MSHybrid o discrete only, perché incide su consumi e frame pacing.
SSD: sequenziale, 4K e copia mista senza falsi positivi
Gli SSD possono gonfiare i numeri grazie alla cache SLC. Per test onesti: misurare con fio o CrystalDiskMark velocità sequenziale (1 MiB QD=1/8) e 4K casuale (QD=1/4/16), poi una copia mista di ~30 GB composta da file grandi (video 4K) e migliaia di piccoli (albero sorgente). Eseguire anche un test di scrittura lunga (>100 GB) per osservare la velocità una volta esaurita la cache.
Standardizzare lo stato dell’unità: spazio libero al 20–50%, TRIM eseguito, termica stabile. Loggare temperatura NAND e throughput nel tempo per cogliere throttling. Per confronto tra laptop, specificare interfaccia (PCIe 3/4/5), linee disponibili e presenza di criptaggio hardware/software attivo.
Autonomia: scenari realistici e script ripetibili
Misurare la batteria richiede scenari chiari. Definire tre profili: 1) ufficio/web con navigazione scriptata (Selenium + loop su 10 siti, scorrimento e video embedded 720p), 2) streaming con riproduzione locale o web 1080p H.264 a luminosità 200 nit e Wi-Fi attivo, 3) creatività leggera con export foto batch (es. 100 RAW in JPEG) o timeline 1080p breve. Usare BrowserBench Speedometer solo per carichi brevi; non è un test di autonomia completo.
Per coerenza: avviare al 100%, disabilitare la sospensione, loggare con powercfg /batteryreport (Windows) o upower (Linux). Riportare tempo di esecuzione, media Watt e Wh consumati. Se la piattaforma supporta panel self refresh o graphics switch, dichiararlo: può cambiare i risultati di oltre il 10%.
Scripting, logging e lettura corretta degli outlier
Automatizzare riduce il rumore. Su Windows, uno script PowerShell può impostare il power plan, lanciare benchmark, avviare HWiNFO in data logging e salvare CSV. Su Linux, Bash o Python gestiscono fio, Blender CLI, nvidia-smi e raccolta metadati. Ogni run produce un pacchetto con: configurazione, versioni, ambientali e log sensori sincronizzati temporalmente.
Per gli outlier, applicare una regola IQR: valori oltre 1,5×IQR dai quartili sono sospetti. Prima di scartarli, cercare la causa: picchi di temperatura (throttling), processi in background, caduta di velocità per cache SSD esaurita. Riportare sempre mediana e percentili (p5/p95) oltre alla media. Se gli outlier persistono, segmentare il grafico nel tempo: spesso rivelano un comportamento ciclico o un limite di potenza intermittente.
Dataset, configurazioni consigliate e replicabilità
Per garantire replicabilità, usare dataset open e linkabili: scene Blender (Classroom, Barbershop), clip video come Tears of Steel 4K e Sintel 1080p per HandBrake/ffmpeg, pacchetti di file misti con 30 GB tra video e il sorgente del kernel Linux. Fissare parametri: preset x264 slow, qualità CRF 18/22, thread bloccati al numero di core fisici, risoluzioni e preset fissi per 3DMark e Unigine. Documentare ogni eccezione.
Per mantenere la serie storica, archiviare i log e rieseguire i test dopo aggiornamenti di BIOS, driver e sistema: piccoli cambiamenti possono alterare i risultati del 2–10%. Creare un changelog dei run con data, motivazione e differenze: aiuta a capire se un miglioramento è reale o frutto di un update fortunato.
