With PHP 5.5 now set as the minimum it is possible to use generators.

http://php.net/manual/en/language.generators.overview.php

Quoting from the PHP manual:

Generators provide an easy way to implement simple iterators without the overhead or complexity of implementing a class that implements the Iterator interface.

A generator allows you to write code that uses foreach to iterate over a set of data without needing to build an array in memory, which may cause you to exceed a memory limit, or require a considerable amount of processing time to generate. Instead, you can write a generator function, which is the same as a normal function, except that instead of returning once, a generator can yield as many times as it needs to in order to provide the values to be iterated over.

I'm personally interested in writing code using this mechanic, but what areas of the code could best benefit from this switch.

This ticket shares its parent's priority and tags.

Comments

dawehner’s picture

Priority: Critical » Major

Why I would really encourage us to use the yield statement in general (potentially even for more than just generators)
I can't see why this should be critical. Would you release without it?

https://nikic.github.io/2012/12/22/Cooperative-multitasking-using-corout... is a great blog post about the yield statement and that generators are just the start.

Aki Tendo’s picture

I was merely mirroring the parent's tags and priority level. Sorry.

dawehner’s picture

No problem. To be clear generators are not the holy grail in performance, I mean, if you need to do the same kind of work and you are not creating HUGE amount of data to even get started with your foreaches, yields not necessarily safe you anything but even make it worse.

Crell’s picture

I don't know how much runtime performance generators would gain us. I'd expect it more to save us lines of code, if we find places to use it.

I'm all for using generators if we find a place for them, but I don't know that there's any significant CPU benefit...

tim.plunkett’s picture

Issue tags: -Performance, -D8 Accelerate, -revisit before release

None of these are demonstrably applicable.

pounard’s picture

Mostly generators can make you gain memory when iterating over very large result sets, depending on what's your source. But it certainly would be a good idea in DBTNG, in some cases I guess, pretty much anywhere where you iterate over SQL results to modify the data and return some array, you can just iterate over a generator instead without creating ever the intermediate array. It may also just avoid creating two arrays in the first place...

twistor’s picture

@pounard, yeah that. I can see possible memory savings, but I very much doubt any performance gains.

pounard’s picture

Iterating only once is better than twice, and even if the gain is minimal, it's still a good school use case, I guess it might not worth the shot of chasing those use case except for pure fun, but it's would be definitely logical to convert them as you see it.

Crell’s picture

So are there specific places in code we can suggest? This meta discussion isn't that helpful until we see some examples.

DB result handling is almost always just a PDOStatement object, which is a C-level object that's already traversable so there's not much more for us to do in general...

pounard’s picture

There actually is a few methods which are build an intermediate array, such as fetchAllAssoc() and fetchAllKeyed(), but they are the only one I could find, and for those two I don't think a generated would gain much since most people will probably use the result as-is.

Crell’s picture

Yeah, fetchAllAssoc() is intended for use when you want random lookup, and fetchAllKeyed() is generally added directly to a form array as-is. A generator wouldn't work for either of those.

Any others? Anywhere in core?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Active » Closed (outdated)

More information was asked here seven years ago and none has been provided. That is, no specific places where code should be changed to use yield. And yield is being used in core now.

I think this can be closed as outdated, because yield is now used in core as needed.