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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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: Fri Oct 18 04:01:29 2024 UTC