php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #77980 why remove --disable-opcache-filecache
Submitted: 2019-05-07 11:02 UTC Modified: 2019-05-07 11:31 UTC
From: spam2 at rhsoft dot net Assigned:
Status: Not a bug Package: opcache
PHP Version: Next Major Version OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: spam2 at rhsoft dot net
New email:
PHP Version: OS:

 

 [2019-05-07 11:02 UTC] spam2 at rhsoft dot net 
Description:
------------
how does the fact that something is no longer experimental justify bloated binaries with unused code? frankly i don't want having "systemctl reload httpd" not clear the opcache and i don't want bloatet binaries

if you want to to do something useful move the core into a loadable so-file instead have it twice in /usr/bin/php and /usr/lib64/httpd/modules/libphp7.so and make both a tiny shim-loader

----------------------

http://git.php.net/?p=php-src.git;a=commitdiff;h=c32da66e129897f4f103ecc6319332f160ee52ea

Remove --disable-opcache-filecache option
This is no longer an experimental feature, and we have the ability
to control this at runtime via an ini setting.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-05-07 11:07 UTC] requinix@php.net
-Status: Open +Status: Wont fix
 [2019-05-07 11:08 UTC] nikic@php.net
-Status: Wont fix +Status: Not a bug
 [2019-05-07 11:08 UTC] nikic@php.net 
Because nobody ever tests the --disable-opcache-filecache build and IIRC it was broken at the time due to a missing #ifdef. A marginally smaller binary is not a reason to keep around this option. This does not make up any significant part of the binary.
 [2019-05-07 11:12 UTC] spam2 at rhsoft dot net 
it makes a significant part of the opcache.so binary and testing these days is the job of a computer and not humans 

we use that option since it exists *because* it makes opcache.so significant smaller and it was never broken except maybe PHP7.3 which is curently out-of-scope here given the large amout of bugs which slowly go in a direction to call it "stable"
 [2019-05-07 11:31 UTC] nikic@php.net 
Please provide specific numbers for the significant size increases you are seeing, as well as which compile options they were produced under.
 [2019-05-07 11:33 UTC] spam2 at rhsoft dot net 
around 20% with a highly optimized PGO build as far as i remember
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Dec 22 06:01:30 2024 UTC