Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance regression when unpacking a generator yielding objects #9030

Closed
TRowbotham opened this issue Jul 16, 2022 · 2 comments
Closed

Performance regression when unpacking a generator yielding objects #9030

TRowbotham opened this issue Jul 16, 2022 · 2 comments

Comments

@TRowbotham
Copy link
Contributor

Description

When unpacking a generator that yields objects, it takes considerably longer to unpack that generator on PHP 8.1 when compared to PHP 8.0. The regression appears to have been introduced somewhere between 8.1.0alpha2 and 8.1.0alpha3.

On my machine, unpacking the generator full of objects takes roughly 85ms on PHP 7.4.24 and PHP 8.0.21, but that time increases to roughly 165ms on PHP 8.1.8.

<?php

ini_set('memory_limit', '100M');

class Foo
{
    private int $data;

    public function __construct(int $data)
    {
        $this->data = $data;
    }
}

function gen_obj(): Generator
{
    for ($i = 0; $i < 1_000_000; ++$i) {
        yield new Foo($i);
    }
}

$startTime = hrtime(true);
$arr = [...gen_obj()];
$endTime = hrtime(true);
printf("Time taken: %.03fms\n", ($endTime - $startTime) / 1_000_000);

Slightly more comprehensive comparison of unpacking vs alternatives iterator_to_array and foreach, with a generator that yields integers and one that yields objects:
https://gist.github.com/TRowbotham/322b29b74a07e12532d52ba331a70bd7

PHP Version

8.1.8

Operating System

Ubuntu 20.04

@cmb69
Copy link
Contributor

cmb69 commented Jul 17, 2022

Looks like this performance regression has been caused by 52cf7ab.

@cmb69
Copy link
Contributor

cmb69 commented Jul 22, 2022

Looks like this performance regression has been caused by 52cf7ab.

Indeed. However, that commit looks correct, and I don't see a way to improve the performance without potentially reintroducing the mentioned leaks. And since you could call gc_disable() (and later gc_enable()) to get back the previous performance, I'm closing this as WONTFIX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants