Polling vs Interrupts: CPU Cost Explained

Two ways to handle events:

• Polling → you keep checking
• Interrupts → hardware tells you when it’s ready

That’s it. But the cost difference is huge.

Polling is basically:
“Is it done?”
“Now?”
“Now??”

The loop runs continuously, checking a flag or register. Even if nothing happens, the CPU is still working.

What you pay:

• CPU cycles wasted doing nothing useful
• higher power usage
• slower response if you check less frequently

Simple to write. Expensive to run.

With interrupts, the CPU doesn’t keep checking. It just does other work (or idles).

When an event happens:

• hardware fires an interrupt
• CPU pauses current task
• runs handler (ISR)

Done.

What you pay:

• interrupt entry/exit overhead
• context switch costs
• more complex code (shared states, race conditions)

But there is no constant checking.

With polling:

• tight loop → wastes CPU entirely
• slow loop → misses timing / drops events

With interrupts:

• too many interrupts → system chokes
• heavy ISR → everything slows down and deadlines are missed
• unprotected shared data → catastrophic race conditions

Nobody uses just one.

• polling for simple, incredibly fast, and deterministic checks (like flag checks during short setups)
• interrupts for external, slow, or unpredictable events (like UART Rx, timers, button presses)

Good systems mix both seamlessly depending on the context constraints.

If you’re checking something thousands of times for no reason → use an interrupt.

If it must be checked immediately, sequentially, and constantly for just a microsecond → polling might be fine.