Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111690
MIME-Version: 1.0
References: <CAF+90c-UQF1u6RSE1H-WDwGVBpB--+ta8axeTtu5D=3mrww0zQ@mail.gmail.com>
In-Reply-To: <CAF+90c-UQF1u6RSE1H-WDwGVBpB--+ta8axeTtu5D=3mrww0zQ@mail.gmail.com>
Date: Wed, 26 Aug 2020 09:52:08 +0200
Message-ID: <CACsECNcD=QYD7HAmKAodjSs-CONnFOiwKLUUkv70Xgwq1g4FRw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bb591705adc319e0"
Subject: Re: [PHP-DEV] Session mm support
From: alexinbeijing@gmail.com (Alex)

--000000000000bb591705adc319e0
Content-Type: text/plain; charset="UTF-8"

I guess the first question is: Why is it so slow? I don't think that using
shared memory to store data is inherently slower than storing it anywhere
else.

It might be that spending an hour or two profiling and optimizing could
slash this time right down.

On Wed, Aug 26, 2020 at 9:37 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> I've recently found out that compiling PHP with --with-mm has a massive
> negative impact on PHP startup performance (approximately 3-4 times
> slower), to the point that our CI got approximately 2x slower overall with
> it enabled. This is not great.
>
> As I only found out about the existence of this session backend recently,
> I'm wondering how widely it is used, and whether we wouldn't be better off
> dropping it from php-src. The performance characteristics make it a pretty
> big foot-gun.
>
> Regards,
> Nikita
>

--000000000000bb591705adc319e0--