ID: 45421 User updated by: rpeters at icomproductions dot ca Reported By: rpeters at icomproductions dot ca Status: Bogus Bug Type: Feature/Change Request Operating System: CentOS 4.3 PHP Version: 5.2.6 New Comment:
I don't have the expertise to develop a patch for PHP. And the issue with PHP is that it's currently impossible for opcode caches to correctly deal with __FILE__ in a hardlinked file. This is due to the fact that __FILE__ (and __DIR__) is inherently dynamic, but is compiled as a constant. _That's_ PHP's problem. There are currently no workarounds or any other mechanisms for allowing proper opcode caching. There is no way for a third party to work around this PHP design flaw, only you have the power to change this. Hence the _feature request_ (not bug report) that one be introduced. I think it's in everyone's best interest if PHP opcaches are usable in more situations than are currently possible. Previous Comments: ------------------------------------------------------------------------ [2009-08-19 18:05:16] [email protected] There isn't anything to fix in PHP, if you think we should do something differently then please submit a patch and we'll review it. ------------------------------------------------------------------------ [2009-08-19 17:23:10] rpeters at icomproductions dot ca So if I want this request re-examined, what do I need to do? I think the support of opcode caches should be of importance to PHP devs and users alike, and want to ensure this gets a fair examination rather than being dismissed out of hand like it has been so far. ------------------------------------------------------------------------ [2008-07-09 15:29:27] rpeters at icomproductions dot ca Since this has not received comment, I take this to mean that the PHP developers do not care that their design choices make it impossible to cache some PHP applications, even though they were designed using recommended features that have no alternatives (like __DIR__). I would have thought that ensuring there was an efficient way to cache PHP applications, and thereby improve PHP's performance, would have a high priority, and not be considered "bogus". I'm saddened to learn otherwise. ------------------------------------------------------------------------ [2008-07-02 23:03:32] rpeters at icomproductions dot ca The problem is not in the cache, as they see it. The problem is that __FILE__ BECOMES opcode, rather than being evaluated at runtime as needed due to hardlinks. They are simply caching the opcode that PHP provides. This seems reasonable to me as well, except for the fact that __FILE__ becomes unusable if it's cached. It's unreasonable for an opcache to parse the PHP file for use of __FILE__ due to performance reasons, so I'm asking PHP to play nice by providing a feature that will allow the opcache to perform efficiently, while maintaining needed PHP functionality. Or, alternatively, to clean up the opcodes provided to the caches (xCache, eAccelerator, etc all suffer from this issue) so that __FILE__ isn't evaluated until after the opcode is generated. ------------------------------------------------------------------------ [2008-07-02 22:56:50] [email protected] realpath($_SERVER['PHP_SELF']) but that's mainly for the executing file. You're asking us to add a feature for what is essentially a problem with the opcode cache, there is no problem with PHP in this case. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45421 -- Edit this bug report at http://bugs.php.net/?id=45421&edit=1
