Re: [Declined] Opcache optimization without any caching
| From: | Nikita Popov | Date: | Sat, 13 Jun 2020 15:37:47 +0000 |
| Subject: | Re: [Declined] Opcache optimization without any caching | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-110503@lists.php.net to get a copy of this message | ||
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á�`ü*ßÁ
> * M«;˜ä
> ,
> 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
>
>