When would polling for events be better than using observer pattern?

Question

Are there scenarios where polling for events would be better than using the observer pattern? I have a fear of using polling and would only start using it if someone gave me a good scenario. All I can think of is how the observer pattern is better than polling. Conside this scenario:

You are programming a car simulator. The car is an object. As soon as the car turns on, you want to play a "vroom vroom" sound clip.

You can model this in two ways:

Polling: Poll the car object every second to see if it's on. When it's on, play the sound clip.

Observer pattern: Make the car the Subject of the observer pattern. Have it publish the "on" event to all observers when itself turns on. Create a new sound object that listens to the car. Have it implement the "on" callback, which plays the sound clip.

In this case, I think the observer pattern wins. Firstly, polling is more processor intensive. Secondly, the sound clip does not immediately fire when the car turns on. There can be up to a 1 second gap because of the polling period.

Answer 1

Imagine you want to get notified about every engine cycle, e.g. to display an RPM measurement to the driver.

Observer pattern: The engine publishes an "engine cycle" event to all observers for each cycle. Create a listener that counts events and updates the RPM display.

Polling: The RPM display asks the engine at regular intervals for an engine cycle counter, and updates the RPM display accordingly.

In this case, the observer pattern would probably loose: the engine cycle is a high-frequency, high-priority process, you don't want to delay or stall that process just to update a display. You also don't want to thrash the thread pool with engine cycle events.

---

PS: I also use the polling pattern frequently in distributed programming:

Observer pattern: Process A sends a message to process B that says "each time an event E occurs, send a message to Process A".

Polling pattern: Process A regularly sends a message to process B that says "if you event E occured since the last time I've polled, send me a message now".

The polling pattern produces a bit more network load. But the observer pattern has downsides, too:

• If process A crashes, it will never unsubscribe, and process B will try to send notifications to it for all eternity, unless it can reliably detect remote process failures (not an easy thing to do)
• If event E is very frequent and/or the notifications carry a lot of data, then process A might get more event notifications than it can handle. With the polling pattern, it can just throttle the polling.
• In the observer pattern, high load can cause "ripples" through the whole system. If you use blocking sockets, these ripples can go both ways.

Answer 2

Polling has some disadvantages, you basically stated them already in your question.

However, it can be a better solution, when you want to truly decouple the observable from any observers. But sometimes it might be better to use an observable wrapper for the object to be observed in such cases.

I'd only use polling when the observable can't be observed with object interactions, which is frequently the case when querying databases for example, where you can't have callbacks. Another issue might be multithreading, where it's often times safer to poll and process messages rather than invoking objects directly, to avoid concurrency issues.

Answer 3

Polling is better if the polling process runs considerably slower than the things it polls. If you are writing events to a database, it's often better to poll all your event producers, collect all the events that have occurred since the last poll, then write them in a single transaction. If you tried to write every event as it occurred, you might not be able to keep up and eventually would have problems when your input queues filled up. It also makes more sense in loosely-coupled distributed systems, where latency is high or connection set-up and tear-down are expensive. I find polling systems easier to write and understand, but in most situations observers or event-driven consumers seem to offer better performance (in my experience).

Answer 4

Polling is a lot easier to get to work over a network when connections may fail, servers may go done etc. Remember at the end of the day a TCP socket needs “polling” keep-a-live messages otherwise the server will assume the client has gone away.

Polling is also good when you wish to keep a UI updated, but the underlying objects change very fast, there is no point update the UI more than a few times a second in most apps.

Provided the server can response “no change” at very low cost and you don’t poll too often and you don’t have 1000s of clients polling, then polling works very well in real life.

However for “in memory” cases, I default to using the observer pattern as it is normally the least work.

Answer 5

For a good example of when polling takes over from notification, look at operating system networking stacks.

It was a big deal for Linux when the networking stack enabled NAPI, a networking API that allowed the drivers to switch from an interrupt mode (notification) to a polling mode.

With multiple gigabit Ethernet interfaces the interrupts would often overload the CPU, causing the system to run slower than it ought to. With polling the network cards collect packets in buffers until polled or the cards even write the packets into memory via DMA. Then when the operating system is ready it polls the card for all of its data and does the standard TCP/IP processing.

The polling mode allows the CPU to collect Ethernet data at its maximum processing rate without useless interrupt load. The interrupt mode allows the CPU to idle between packets when work is not so busy.

The secret is when to switch from one mode to the other. Each mode has advantages and should be used in the proper place.