Hi internals, Currently, it isn't possible to enable optimizations without enabling caching. They should be orthogonal features - it's already possible to cache without optimization passes (`opcache.optimization_level=0`)
I have a prototype implementing this at https://github.com/php/php-src/pull/5504 . Conceptually, this behaves like opcache.file_cache_only in that it optimizes and doesn't use any shared memory, but doesn't actually save or load files. I wanted to measure interest in an RFC to add this to PHP, and on what form this should take. (I've heard PR discussion is supposed to be for implementation details, so I'm also creating an email thread) Being forced to either enable caching or file_cache_only causes these problems: - For file_cache_only, users would be forced to manage the file cache, and users may not be confident in properly handling all potential edge cases. (Running out of disk space, need to clear stale entries, concerns about opcode corruption not being fixed after restarting a process, etc) - The shared memory block uses up a lot of RAM when individual PHP processes are known to be long-lived and don't have a common memory address space. (e.g. multiple long-lived php scripts managed by something that is not a php script (e.g. `supervisord`, daemons, tools run in the background in IDEs, etc). Typical web server uses such as apache share a process space, and would not use no_cache) The opcodes are duplicated in shmem, which wastes memory in use cases where they're stored in the cache but never retrieved. The default for opcache.memory_consumption is 128M. Even when this isn't used, the virtual memory to track the shared memory(shmem) segment seems to add 2MB extra per **independent** php process in "shared memory" segments (depending on OS settings?), reducing the free RAM available for other processes. (starting a large number of php CLI scripts that sleep() in a loop, `free` (linux program to report free memory) reports that `shared` increases by 2MB per process without opcache.no_cache, but barely increases with opcache.no_cache=1 On an unrelated PR https://github.com/php/php-src/pull/5097#issuecomment-576421941 Dmitry Stogov mentioned that > Also, it would be great to move optimizer and JIT into core, to make them > available even without opcode caching. On the PR itself, Nikita Popov wrote https://github.com/php/php-src/pull/5504#issuecomment-622295467 > I like the idea of having optimization without caching, > but the way to go about this is definitely moving the optimizer into Zend > and making it available completely independently of the opcache extension. > This has been "planned" for a long time, but never actually happened. - I think that creating a new setting along the lines of opcache.no_cache would have a use case before and after such a refactoring, providing the benefits I mentioned for the use cases in the PR description. This would continue to be have a use case even if the caching parts of opcache.so moved into php's core (e.g. if that was done, and the caching module were loaded in php.ini as zend_extension=opcache.so, there'd still be a use case for a configuration setting to override that default to disable caching for running individual programs) Users may strongly prefer for `opcache.enable`, `opcache.enable_cli`, and `opcache.optimization_level` to continue controlling whether optimizations are performed (so setting the combination of `opcache.enable=1`, `opcache.enable_cli=1`, and a setting such as `opcache.no_cache=1` to optimize without caching would make sense there) - If nobody's currently planning to work on moving the optimizer into Zend (i.e. into php's core), then it may be several minor releases before it's possible to have optimization without caching. - There may be unforeseen objections to moving the optimizer into Zend from creators/users of profiling tools, debuggers, code coverage tools, etc. Hopefully not, but that'd depend on the proposed implementation details. Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
