Apple Silicon’s Hidden Performance Secret: Why E-Cores Actually Make Your Mac Fast
Understanding Quality of Service and the architecture that keeps background tasks where they belong
The Counterintuitive Truth
Ask most people why their Apple Silicon Mac is fast, and they’ll point to the Performance cores. It’s in the name, after all. But the unsung hero of the architecture is actually the Efficiency cores—and more specifically, how they keep background tasks from interfering with your work.
The First Ten Minutes
Here’s an experiment: Cold-start your Apple Silicon Mac and open Activity Monitor with its CPU History window. For the first five to ten minutes, you’ll see the E cores as a wall of red and green:
- Spotlight indexing services
- CGPDFService
- mediaanalysisd
- BackgroundShortcutRunner
- Siri components
- Time Machine backup
- XProtect Remediator scan
Meanwhile, the P cores? Largely idle.
If you were to dive straight into working, there’s plenty of capacity for your apps to run unaffected by all that background mayhem.
The Intel Mac PTSD
This is where users coming from Intel Macs get nervous. Seeing processes using more than 100% CPU looks terrifying because Intel cores can struggle under heavy load, affecting user applications. The spinning beachball was a common sight.
But on Apple Silicon, a dozen mdworker processes each taking 50% CPU simultaneously? The architecture is literally designed for this.
The Psychology Problem
There’s a visual deception at play. Activity Monitor shows E cores at 100% and P cores at 100% using the same scale—but they’re not equivalent.
Measured frequencies (M4 Pro example):
– P cores running high-QoS threads: ~4,512 MHz
– E cores running low-QoS threads: ~1,050 MHz
– E cores running overflow high-QoS threads: ~2,592 MHz
That low-QoS E core frequency? About one quarter of the P core maximum. The visual comparison is completely misleading.
Quality of Service: The Real Innovation
While big.LITTLE architecture has existed since ARM announced it in 2011, and Apple brought it to iPhone 7 in 2016, what makes the difference in Apple Silicon Macs is Quality of Service (QoS).
QoS has been in macOS since Yosemite (2014), but back when all CPU cores were identical, it had limited usefulness. Lowering a background task’s priority only prolonged how long it competed for CPU cycles—the work still had to be done somewhere.
The Key Distinction
With heterogeneous cores, QoS makes a fundamental distinction:
| Thread Type | P Cores | E Cores |
|---|---|---|
| Foreground (high QoS) | Primary | Overflow |
| Background (low QoS) | Not allowed | Restricted |
Background threads aren’t normally allowed to run on P cores, even if delayed by E core load. You can’t even force them there using tools like App Tamer or taskpolicy.
Why This Matters
This design choice prevents the degradation that would occur if background and foreground work could freely mix. Even when you see those E cores maxed out after startup, macOS won’t try running background tasks on idle P cores because:
- The foreground/background distinction would break down
- User apps would suffer from competition
- Battery endurance would decline
Gone are the days of crashing mdworker processes bringing Macs to their knees.
The Architecture Implication
Modern macOS breaks applications into discrete processes:
An idle Mac has over 2,000 threads running in over 600 processes.
This is good news. The more tasks that can be backgrounded to E cores, the faster your foreground apps run. It’s why every M-series chip since the M1 Pro/Max has had at least four E cores, with some having six or eight.
Technical Tags
#Apple-Silicon #CPU-Architecture #Quality-of-Service #macOS #Performance-Optimization #ARM #Activity-Monitor
Key Takeaways
- E cores enable P core performance by offloading background work
- QoS provides hard boundaries between foreground and background execution
- Activity Monitor’s visualization is misleading – 100% on E vs P isn’t equivalent
- More processes is architecturally sound – it enables better core allocation
- Background tasks can’t promote themselves to P cores, preserving user experience
The best performance optimization is often about what you keep away from the fast path, not just how fast the fast path runs.