Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110503
MIME-Version: 1.0
References: <DM6PR07MB6618FCA81C269B3CCE7FB566F99E0@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB6618FCA81C269B3CCE7FB566F99E0@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Sat, 13 Jun 2020 17:37:47 +0200
Message-ID: <CAF+90c8jGc1m4oeVJuPg+rAjFfTpC-AEOJO7Rtti0zE4JRgv_A@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000aeac7e05a7f8fa62"
Subject: Re: [PHP-DEV] [Declined] Opcache optimization without any caching
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000aeac7e05a7f8fa62
Content-Type: text/plain; charset="UTF-8"

On Sat, Jun 13, 2020 at 5:08 PM tyson andre <tysonandre775@hotmail.com>
wrote:

> Hi internals,
>
> https://wiki.php.net/rfc/opcache.no_cache has been declined, with 10 yes
> votes and 13 no votes.
>
> The "If you voted no, why?" section indicates that there was broad support
> for moving opcache optimizations outside of the zend_extension and into
> core instead of this approach.
>
> After the RFC ended, I added a section with some rough ideas for
> implementation details of how moving optimizations into core instead would
> be done (while continuing to support existing php use cases efficiently)
> in
> https://wiki.php.net/rfc/opcache.no_cache#ideas_on_moving_the_optimizer_into_core_instead
> ,
> but ran into roadblocks trying to implement it.
>

To be clear, "move into core" means moving optimizations into Zend/ and
making them part of the compilation process (optionally). They shouldn't be
in a separate ext/optimizer extension -- that would be not much better than
having them in ext/opcache :)

Nikita


> I probably won't end up implementing this, because it's a much more
> extensive refactoring.
> I'm not familiar enough with opcache to know if what I'd implement would
> end up working on all platforms (threaded vs non-threaded, windows memory
> management, etc),
> or if it'd interfere with existing debuggers/profiles, or have other
> shortcomings I didn't anticipate.
>
> Thanks,
> - Tyson
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--000000000000aeac7e05a7f8fa62--