Your Device is Cheating on You.

I trusted my laptop. I saved up for it, I researched it, and I defended it in arguments like it was my child. And how did it repay me?

By cowardly playing it safe. Throttling itself before it even broke a sweat, sitting on its own potential like it was afraid of what it could become. And quietly, in the background, 250 processes I never asked for were running, eating my RAM like it was a free buffet.

My laptop was cheating on me. And the worst part? It had been doing it since day one.

So I put on my detective hat, and just like that, Shikhar Holmes was on the case. If this thing had been holding out on me since day one, I was going to catch it in the act.

The Sting Operation: Finding the Perfect Suspect

I always had my suspicions. The random frame drops, the sluggishness, the feeling that my laptop was capable of more than what it was actually giving me. But even the best detective needs stone-cold evidence, and right now, all I had was a theory.

Now the question was, how exactly was I supposed to catch a laptop in the act?

Enter benchmarking: Wonder Woman’s lasso of the tech world. It strips away assumptions and shows what your machine is actually delivering.

And this was bigger than my laptop. My HP Victus wasn’t some lone perpetrator; this entire ecosystem was a carefully coordinated cabal of devices quietly cheating their users in broad daylight.

This was organized crime.

Performance laundering had gone corporate.

And if Shikhar Holmes was going to bring the whole operation down, it was time to run a little experiment.

To get this experiment started, I needed a test subject. Naturally, I thought about starting with the prime offender sitting before me: my laptop.

The problem was, this little criminal and I had too much history together. If I wanted results I could actually trust, I needed a cleaner crime scene.

That’s when the investigation caught its first real break.

If I wanted a suspect that hadn’t already been compromised, I needed a fresh one. So I hopped onto VirtualBox and spun up a fresh Windows 11 virtual machine. A virtual machine emulates an entirely separate operating system inside your existing system, making it isolated, repeatable, and perfect for controlled testing, exactly what the investigation needed.

To keep the VM realistic without turning it into a heavy system, I added a few everyday applications: Chrome, ShareX, Spotify, Steam, VLC, WinRAR, and the necessary benchmarking tools. Nothing extreme, just enough to simulate a lightly used but active Windows setup.

And just like that, we finally had our suspect.

A fresh install for some fresh allegations.

The Investigation Begins: Benchmarking the Betrayal

With the perfect suspect finally in place, it was time to step into the crime scene and start gathering evidence.

Every system leaves traces when it runs, and the goal here was simple: capture and log those traces through benchmarks and profiling, and turn them into evidence.

So I put together a small but potent forensic arsenal designed to expose different layers of system behavior under pressure, each revealing a different part of the story. Here’s the setup I was working with, and the evidence it procured.

The first tool on the table was **Geekbench 6*, our benchmarking software for measuring raw CPU performance under controlled conditions.* It runs a set of workloads that simulate tasks like compression and processing, then asks the processor one simple question: What are you actually capable of?

The single-core and multi-core scores are shown below, and you can check out the detailed report here.

Single-core runs the errands, multi-core lifts the furniture.

Next came Task Manager’s CPU view, the real-time confession booth. Unlike Geekbench, which shows controlled performance, this reveals how the processor behaves during actual system activity, showing whether it can sustain performance under load or starts to struggle in real conditions.

Real workloads come with background baggage.

Memory usage told a different part of the story. This is where background processes, startup services, and hidden system overhead show how much of the system is already occupied before anything even begins, often leading to paging when RAM runs low, which impacts responsiveness.

RAM had developed a squatter problem.

Storage performance was tested using **CrystalDiskMark*, which measures how quickly the drive handles reads and writes across different patterns. This matters because nearly everything on a system eventually depends on disk access, meaning storage speed quietly sets the ceiling* for overall responsiveness.

Slow reads and writes make even the fastest systems wait.

Resource Monitor added another layer, showing what is actively using the disk in real time. It reveals which processes are reading and writing in the background and how much they’re competing for storage bandwidth, often explaining slowdowns that raw speed tests alone can’t capture.

Disk traffic had entered rush hour.

Finally, boot time measured how long the system takes to become usable after powering on. While it looks like a simple convenience metric, it actually reflects how much load Windows is forcing at startup through services and background processes, which immediately affects overall system responsiveness.

89 seconds of startup roll call.

At this point, the system wasn’t being guessed at or interpreted anymore. It was laid bare in numbers, charts, and live behavior under load. Every major layer, from CPU to memory to storage and startup, had left its footprint behind.

The forensic analysis was complete, and the baseline scores were in. But the real story of what these machines were capable of was still waiting to be uncovered.

The Hidden Villains: Processes, Settings, and Throttling

To unveil what these systems were truly capable of, I first had to find the hidden villains holding them back.

The question remained: why would manufacturers spend billions building powerful machines, only to keep them running on a leash?

Turns out, the answer was less sabotage and more compromise.

Modern systems constantly balance a finite pool of resources with a performance budget, dividing it among raw speed, battery life, thermal management, stability, and background processes.

Every extra frame, faster load time, or smoother response has to come from somewhere. Either the system load gets reduced through debloating and optimization, or another part of the performance budget gets sacrificed in return, usually battery life, temperatures, noise, or stability.

Call it the Holmes Principle: performance can neither be created nor destroyed, only redistributed.

Turns out every missing frame leaves a trail.

And once I started tracing where the performance budget was actually going, the biggest redistributors quickly revealed themselves:

• Processes: Startup applications, telemetry, update schedulers, and background services quietly consume CPU time, memory, and storage bandwidth before the user even launches anything demanding.
• Settings: Most systems are configured conservatively out of the box, especially laptops, where power plans and manufacturer limits prioritize battery life, lower temperatures, and quieter operation over maximum sustained performance.
• Throttling: As temperatures or power draw rise, the system intentionally pulls back clock speeds and performance to maintain stability, efficiency, and safe operating conditions.

The holy trinity of performance theft.

While hardware upgrades remain the biggest drivers of performance, a surprising amount can still be unlocked by redistributing the system’s load more efficiently.

Most consumers assume there is little room for improvement without changing hardware, but modern operating systems leave far more performance on the table than people realize.

Now that the system’s tricks were finally out in the open, it was time to see how much performance could actually be reclaimed.

Optimization Quest: Unleashing Hidden Performance

After figuring out what was holding the system back, the next step was obvious. I wasn’t about to fix ten different problems one setting at a time.

Background processes, startup junk, telemetry, power limits, thermal throttling, and bloated visual effects each seemed small on their own, but together they dragged everything down. Fixing it manually felt like playing whack-a-mole with performance.

So I did what any slightly insufferable second-year computer science student (and part-time detective) would do. I went ahead and built my own Windows optimization script from scratch.

So come along, don’t fret, Shikhar Holmes isn’t done yet. Time to crack the case.

Desperate times called for questionable coding decisions.

To build it, I turned to Batch scripting, Windows’ built-in scripting language, keeping the toolkit lightweight, portable, and entirely terminal-based while giving me direct access to Windows’ performance controls.

Next, I had to figure out the core optimization points inside Windows, and a few major ones quickly stood out:

• Windows Registry (regedit): The Registry is basically Windows’ giant configuration database. Hidden inside it are settings controlling things like animation delays, startup behavior, game scheduling priorities, visual effects, and even the Xbox Game DVR overlay.
• Background Services: Windows constantly runs background services like SysMain, Windows Search, and telemetry tracking. Useful in some cases, sure, but they also add a constant layer of overhead running behind the scenes.
• Power Management: By default, Windows aggressively balances performance and efficiency, often throttling CPU speeds earlier than necessary. High-performance power plans loosen those restrictions and let the hardware respond more aggressively under load.
• The Networking Stack: Deep inside Windows are TCP and adapter-level settings that affect latency and packet handling. Features designed to improve efficiency can sometimes add small delays, which become surprisingly noticeable in gaming and real-time applications.

Alongside those core systems were smaller optimization points too, including visual effects settings, NTFS filesystem behavior, temporary caches, and startup program management.

And slowly, after enough registry spelunking, encoding issues that turned terminal output into gibberish, silent administrator permission failures, and broken registry paths, the investigation finally found its smoking gun.

Shikhar Holmes presents: HolmesKit.

HolmesKit is a centralized Windows optimization toolkit built to expose, control, and reclaim the performance modern systems quietly leave on the table.

If you want to investigate what your system is really capable of underneath all the overhead, feel free to check out the HolmesKit GitHub repository and full documentation here.

Unlike most optimization tools that blindly apply tweaks behind a shiny interface, HolmesKit explains exactly what every option changes, what parts of Windows it affects, and how to reverse it if needed, with automatic backups and built-in restore support.

And for our investigation, HolmesKit became both the optimization toolkit and the smoking gun, finally giving us a way to see whether the system had been cheating us all along.

Post-Optimization Benchmarks: The Reckoning

With HolmesKit finally ready, I pulled the trigger on the full optimization pass, applied every tweak we had investigated, and reran the same benchmarks and monitoring tools under identical conditions.

And honestly, I was still a little skeptical. Placebos are a dangerous thing. After hours spent tweaking, cleaning, and optimizing a system, you almost expect the results to improve.

But when the results came back, the difference was impossible to ignore.

The case was closed.

The evidence was finally in, and Geekbench 6 was first up.

The biggest gains showed up where you’d feel them.

The results showed Geekbench’s single-core score increasing from 1687 to 1863, while the multi-core score climbed from 4966 to 5185 after multiple benchmark runs, using the median scores for accuracy.

That translated to roughly a 10% improvement in single-core performance, which affects everyday responsiveness like opening applications and switching windows, and a 4% gain in multi-core performance, which matters more for heavier workloads like gaming and multitasking. The optimized runs were also noticeably more consistent, with far less background interference during testing.

Next came Task Manager’s CPU view, the real-time confession booth.

Idle CPUs were not meant to work overtime.

Idle CPU usage dropped from 17% to just 3% after optimization, while active processes decreased by almost 25%, from 165 to 124, alongside roughly 30% reductions in system threads and active handles.

More importantly, the processor finally had room to focus on actual work instead of spending cycles on background housekeeping.

Memory usage told a similar story.

The squatters had finally been evicted.

RAM usage dropped from 4.7 GB to 3.0 GB at idle, while available memory increased from 3.2 GB to 4.9 GB after optimization, effectively handing back nearly 1.7 GB of usable memory to the system. Memory compression also disappeared entirely, dropping from 52 MB to 0 MB.

The extra headroom gave the system much more breathing room during multitasking, reducing slowdowns and lowering the chances of Windows falling back to slower disk paging.

Then came CrystalDiskMark.

The SSD had stopped tripping over traffic.

Sequential read speeds more than tripled from 165 MB/s to 523 MB/s, while write speeds nearly doubled from 257 MB/s to 505 MB/s after optimization, speeding up file access and application loading. The SSD had not suddenly evolved overnight. The system had simply stopped tripping over its own background activity.

There was one trade-off, though. Random 4K read performance dropped after disabling SysMain’s aggressive RAM caching, though the difference is subtle enough that most users would likely never notice it in everyday use.

Resource Monitor made the issue even clearer.

The disk finally stopped looking under siege.

Before optimization, the drive was constantly busy with indexing, telemetry, startup tasks, and background activity, leaving the disk graph cluttered even at idle. After optimization, however, the graph became far cleaner, with significantly less background contention.

Finally, there was boot time.

Unnecessary services never made it to the roll call.

Boot time saw a major decrease, dropping from ~89 seconds to ~49 seconds after optimization, nearly cutting startup time in half. That meant fewer services competing for resources from the moment the system came alive.

And just like that, the evidence was all there.

For a clearer side-by-side comparison across every tool, here’s a complete summary of the results.

Even Saul Goodman couldn’t save these crooks.

The numbers spoke for themselves.

It was finally time to put these criminals away for good.

Right?

Universal Tips, Takeaways & Closing Thoughts

Well… maybe not.

The evidence was real. The benchmarks were real. The background overhead, throttling, startup clutter, and wasted resources were all undeniably there.

But the deeper the investigation went, the harder it became to treat these machines like outright criminals.

Modern devices are built around the average consumer, and if your priorities fall outside that average, it becomes your responsibility to shape the machine around your own needs instead.

That is precisely why no setup is one-size-fits-all. A machine tuned for someone chasing every possible frame in a game will look very different from one built for a student or office user prioritizing stability and battery.

And often, the best optimization is no optimization at all. The golden rule has always been: “If it isn’t broken, don’t fix it.”

And if you really want to push things further through software, sometimes the answer is not optimizing Windows at all, but moving to leaner setups like older Windows versions or Linux.

At the end of the day, the users have the power, not the machines.

And as I wrote that, a dark realization crossed my mind, interrupted by the police at the door.

Maybe my laptop was never really the criminal.

Maybe I was the criminal all along.

Turns out I had been profiling the wrong suspect.