I Dual-Boot Windows 11 and Ubuntu on the Same Laptop. Here's What Each One Actually Feels Like.

Jeet Patel — Mon, 28 Sep 2026 15:30:00 +0000

I dual-boot Windows 11 and Ubuntu on the same laptop. Ryzen 5 3500U, 8 GB RAM, one SSD.

I am not a hardware reviewer. I am a guy who got tired of one OS feeling like a different, slightly angrier laptop.

Here's the honest breakdown.

Booting up

Windows 11: I log in, and then I wait.

The login itself is fine. The problem is what happens afterward.

For the first four or five minutes, the laptop feels like it's still trying to wake up. Apps take noticeably longer to open, the system feels busy even when I'm not doing anything, and using it doesn't feel smooth yet.

At this point, I've started making coffee after turning it on.

Not because I want coffee.

Because the laptop needs the time.

Ubuntu: type my password, start working.

That's it.

No five-minute warm-up period. No waiting for the system to settle down. If I want to open my editor immediately after logging in, I just open it and start working.

The RAM situation

I do Flutter dev. Flutter wants RAM the way toddlers want your phone: immediately, all of it, no negotiation.

On Windows:

Log in.
Open the editor.
Half my RAM is already gone.
To things I didn't open.
Mouse starts stuttering like a bad video call.
Flutter build: does not happen.

On Ubuntu, RAM climbs to 90-99% during real work and the desktop stays smooth the whole time. I don't fully understand how they do it but it's great to work with.

Quick-fire differences

Things I've noticed just from living in both, no lab coat required:

Customizing the desktop: costs ~150-200 MB extra on Ubuntu. Same kind of customization on Windows: 600-700 MB. Same haircut, very different bill.
Battery life: noticeably better on Linux, maybe 30-40% less drain in a normal day. Measured with vibes, not a stopwatch, but a big enough gap that I noticed without trying.
Fan noise and heat: lower on Ubuntu. I can feel it on my lap. Windows, some days, feels like it's plotting something.
Uninstalled bloatware: stays uninstalled on Ubuntu. On Windows, it comes back after updates like a horror movie villain. I didn't invite you back, Doll.

Where Windows still wins

Gaming. Just gaming.

Plug in, click play, done. Linux gaming has gotten genuinely good, but it's not yet "tell your non-technical friend to switch" good.

Credit where it's due.

Why I even checked

At some point I got curious enough to actually open Task Manager and Ubuntu's Resources app, side by side, both idle, both freshly logged in.

Windows: 70%+ RAM used, with the CPU bouncing around in the background despite me not actually doing anything.

Ubuntu: about a quarter of its RAM or less used, CPU barely awake.

These are screenshots from one laptop on one day. Not a benchmark. Just receipts for a feeling I'd already had for months.

Where I land

Give it enough background processes and Windows will always feel like it's carrying something. Give Linux proper gaming support and a few more years of people just trying it, and I don't think Windows keeps its lead on hardware like mine.

Right now the only things holding people back are habit and Steam.

Anyone else dual-boot and feel this gap? Or is my Windows install just cursed?

From 3ms to 0ms: The Hidden Memory Trap in C++ Maps

Jeet Patel — Tue, 15 Sep 2026 02:12:16 +0000

From 3ms to 0ms: The Hidden Memory Trap in C++ Maps

I thought I was writing the cleanest one-liner of my life.

To solve Two Sum, I stored 1-based indices in an unordered_map so I could check for complements directly inside an if statement:

if (mp[target - nums[i]]) {
    return {mp[target - nums[i]] - 1, i};
}

It passed. But it took 3ms.

On a whim, I swapped that single line to mp.find(). The runtime plummeted straight to 0ms.

Why would two operations that look like basic O(1) lookups perform so radically differently?

The Secret Life of `operator[]`

In C++, square brackets aren't just looking through the window. If the key isn't there, C++ assumes you're lonely and creates a new friend for you on the spot.

When you call mp[missing_key]:

It allocates a brand-new node on the heap.
It inserts missing_key with a default value of 0.
It hands back a reference to that 0.

Because 0 evaluates to false, my if condition technically worked. But behind the scenes, every single failed lookup left a ghost entry behind. My map was hoarding junk data, thrashing CPU caches, and triggering expensive hash table rehashes mid-loop.

mp.find(), on the other hand, is strictly read-only. If the key isn't there, it returns mp.end() and walks away without touching heap memory.

The Fix

// The 3ms Trap: Allocates heap memory for ghost entries on every miss
if (mp[complement]) { ... }

// The 0ms Clean Run: Read-only check, zero allocations
auto it = mp.find(complement);
if (it != mp.end()) {
    return {it->second, i};
}

(Tip: In C++20, if you only care about presence and don't need the value right away, mp.contains(key) gives you the same zero-allocation check with even cleaner syntax).

The Rule of Thumb

Never use [] to ask, "Are you there?"
Square brackets are for modifying data, not window shopping.

Have you ever had an optimization that looked slick on paper but quietly blew up your runtime? Drop your favorite sneaky C++ traps or debugging facepalms in the comments!

DEV Community: Jeet Patel

I Dual-Boot Windows 11 and Ubuntu on the Same Laptop. Here's What Each One Actually Feels Like.

Booting up

The RAM situation

Quick-fire differences

Where Windows still wins

Why I even checked

Where I land

From 3ms to 0ms: The Hidden Memory Trap in C++ Maps

From 3ms to 0ms: The Hidden Memory Trap in C++ Maps