Yield vs Fiber in PHP: When to Choose Each for Efficient Async Code

Overview

In a previous answer I described how PHP changes after introducing Fibers. A reader pointed out that Fibers look similar to yield. After years of development experience and deep study of both features, I discovered significant differences between them.

First

yield

is a unique feature that does not have its own dedicated stack space. When using a yield function, developers face two handling options.

Iterate the generator with a foreach loop.

Use the yield from operator to pass the iterator to the caller, letting the caller perform the iteration.

This mechanism can be inconvenient because the caller must know whether a function is a generator; if it is, extra code is required either to iterate it manually or to delegate iteration outward. In deep call chains this adds noticeable overhead and complexity, resembling JavaScript's await only partially.

Comparison

Fibers, on the other hand, have their own independent call stack, typically consuming about 1 MB of stack memory. A Fiber can suspend execution at any depth using Fiber::suspend(), and resumption is handled only at the outermost Fiber::start scope. Importantly, nested calls do not need to know whether inner functions use Fiber::suspend().

When Fiber::suspend() is invoked, the entire call stack pauses and the CPU returns to the point of the Fiber start or resume. Regardless of call depth—five levels, ten levels, or more—the developer can treat the code like ordinary synchronous calls, with the internal details hidden, greatly simplifying complex logic and reducing cognitive load.

As a Developer

Choosing between yield and Fiber depends on the scenario. For simple iteration tasks, yield may suffice. For complex concurrency and asynchronous operations, Fiber offers stronger capabilities and a cleaner programming model, enabling more efficient implementation of intricate program logic while avoiding unnecessary pitfalls.

Using yield

When using yield, developers must constantly manage the iteration method. Although it saves stack space, in deeply nested calls it can become cumbersome.

Fiber solves this problem with an independent stack and a straightforward pause‑resume mechanism, making it well‑suited for handling deep nesting and concurrent tasks, providing a robust tool for asynchronous programming.

However

While Fiber brings many conveniences, its independent stack incurs memory overhead—about 1 MB per Fiber—which can become significant in large‑scale usage. Developers need to weigh this cost against the benefits and plan resources accordingly.

Conclusion

Developers should flexibly apply these features based on specific use cases and performance requirements, keeping an eye on maintainability and optimization. To run multiple user requests in parallel within a single process using Fibers, one must rewrite I/O functions, avoid functions that change process state, and refrain from using global variables.

Original article source: https://www.zhihu.com/question/450153647/answer/64415228135?utm_psn=1866379328251633664