rfc:optimizerplus

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:optimizerplus [2013/02/13 15:34] – Added source code link zeevrfc:optimizerplus [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Integrating Zend Optimizer+ into the PHP distribution ====== ====== Integrating Zend Optimizer+ into the PHP distribution ======
-  * Version: 0.80+  * Version: 1.01
   * Date: 2013-01-28   * Date: 2013-01-28
   * Author: Zeev Suraski <zeev@php.net>   * Author: Zeev Suraski <zeev@php.net>
-  * Status: Under Discussion+  * Status: Implemented in PHP 5.5
   * First Published at: http://wiki.php.net/rfc/optimizerplus   * First Published at: http://wiki.php.net/rfc/optimizerplus
  
Line 32: Line 32:
 For the most part, the existence of an opcode cache should have no influence on extensions, except for ones that do 'brain surgey' on the Zend engine. For the most part, the existence of an opcode cache should have no influence on extensions, except for ones that do 'brain surgey' on the Zend engine.
  
 +==== Debuggers ====
 One such class of plugins are debugger extensions like Xdebug or Zend Debugger.  Since debugger plugins instruct the engine to generate slightly different code - they actually can influence the behavior of an opcode cache in a negative manner.  However, it should be easy to implement some minimal level of 'awareness' so that when Xdebug or Zend Debugger detect the presence of an opcode cache - they'll take measures to ensure that they don't clash with each other.  Zend Debugger today implements it by simply overriding the compiler callback on its own, prior to Optimizer+ - and invokes the Optimizer+ compiler callback only for requests that don't have debugging enabled.  It should be possible to implement the very same mechanism in Xdebug. One such class of plugins are debugger extensions like Xdebug or Zend Debugger.  Since debugger plugins instruct the engine to generate slightly different code - they actually can influence the behavior of an opcode cache in a negative manner.  However, it should be easy to implement some minimal level of 'awareness' so that when Xdebug or Zend Debugger detect the presence of an opcode cache - they'll take measures to ensure that they don't clash with each other.  Zend Debugger today implements it by simply overriding the compiler callback on its own, prior to Optimizer+ - and invokes the Optimizer+ compiler callback only for requests that don't have debugging enabled.  It should be possible to implement the very same mechanism in Xdebug.
  
 To simplify interaction between such modules, and in order to avoid the need for a strict loading order of modules - we may want to create a new mechanism in the engine that allows zend_extensions to specify the priority of overriding the compiler/executor callbacks.  This is something we can look more deeply into if & when we integrate Optimizer+ into core. To simplify interaction between such modules, and in order to avoid the need for a strict loading order of modules - we may want to create a new mechanism in the engine that allows zend_extensions to specify the priority of overriding the compiler/executor callbacks.  This is something we can look more deeply into if & when we integrate Optimizer+ into core.
 +
 +Finalizing the mechanism is outside the scope of this RFC.
 +
 +
 +==== Other Components ====
 +
 +The Optimizer+ component will not include any non-generic special support for any external components, Zend or otherwise.  Generic support for persisting non-default data structures in shared memory might be added in the future, but is outside the scope of this RFC.
  
  
Line 60: Line 68:
  
 All tests were done with the latest source tree of PHP 5.5.0 as of Jan 28 2013. All tests were done with the latest source tree of PHP 5.5.0 as of Jan 28 2013.
-We've tested plain PHP, APC 3.1.5-dev, Optimizer+ vanilla and Optimizer+ configured for maximum performance.  All tests were done on the same hardware, using PHP in FastCGI mode with 4 worker processes.  We've tested numerous applications, both procedural and object oriented.+We've tested plain PHP, APC 3.1.5-dev, Optimizer+ vanilla and Optimizer+ configured for extreme performance.  Note that tuning for extreme performance may result in certain workflows and/or code structures to no longer work properly, so there's no plan to make these settings default.  All tests were done on the same hardware, using PHP in FastCGI mode with 4 worker processes.  We've tested numerous applications, both procedural and object oriented.
  
 The results are available as a Google Spreadsheet: The results are available as a Google Spreadsheet:
Line 69: Line 77:
  
 The Zend Optimizer+ source code has been made available under the PHP license, and can be found on github at http://bit.ly/VSsqx3 The Zend Optimizer+ source code has been made available under the PHP license, and can be found on github at http://bit.ly/VSsqx3
 +
 +===== Naming =====
 +
 +If the Optimizer+ components becomes embedded in PHP, it's likely that a name change will be in order.  Finalizing the name is outside the scope of the RFC, but it's agreed that the name will be agreed upon by the internals@ community, either through consensus or a vote.
  
 ===== Recommendation ===== ===== Recommendation =====
Line 77: Line 89:
 ===== Suggested Roadmap ===== ===== Suggested Roadmap =====
  
-  - As the code becomes available, put it in PECL.+  - Make the source code available [DONE]
   - Once the cleanup / initial improvements are done and everything is working & stable - bundle in PHP and move to ext/.   - Once the cleanup / initial improvements are done and everything is working & stable - bundle in PHP and move to ext/.
-  - Long term, evaluate whether it makes sense to further integrate right into Zend/.+  - Decide (on internals, or using a separate RFC/vote) whether to enable by default. 
 +  - Long term (beyond PHP 5.5), evaluate whether it makes sense to further integrate, and create tighter coupling with the Zend Engine.
  
 ===== PHP 5.5.0 ===== ===== PHP 5.5.0 =====
  
-If the RFC gets approved, one open question is whether or not we should aim for integrating Optimizer+ into the PHP 5.5.0 release.  While integrating Optimizer+ could probably be done fairly quickly and without greatly delaying PHP 5.5.0’s timeline, it may require a 1-2 month delay.  The question on the table is whether most users would prefer a slightly later release with an out-of-the-box working opcode cache, or a slightly earlier release without a compatible opcode cache available for several additional months.  It should be noted that if we don’t integrate it in 5.5.0, based on the current timelines and versioning rules, the integration won’t happen before late 2014.+If the RFC gets approved, one open question is whether or not we should aim for integrating Optimizer+ into the PHP 5.5.0 release.  While integrating Optimizer+ could probably be done fairly quickly and without greatly delaying PHP 5.5.0’s timeline, it may require a 1-2 month delay.  The question on the table is whether most users would prefer a slightly later release with an out-of-the-box working opcode cache, or a slightly earlier release without a compatible opcode cache available for several additional months.  It should be noted that if we don’t integrate it in 5.5.0, based on the current timelines and versioning rules, the integration won’t happen before mid-late 2014.
  
-===== Suggested Voting Options =====+The integration proposed for PHP 5.5.0 is mostly 'soft' integration.  That means that there'll be no tight coupling between Optimizer+ and PHP;  Those who wish to use another opcode cache will be able to do so, by not loading Optimizer+ and loading another opcode cache instead.  As per the Suggested Roadmap above, we might want to review this decision in the future;  There might be room for further performance or functionality gains from tighter integration;  None are known at this point, and they're beyond the scope of this RFC. 
 + 
 +===== Vote ===== 
 + 
 +Vote starts Feb 27th, and ends March 7th 
 + 
 +<doodle title="rfc/optimizerplus" auth="user" voteType="multi" closed="true"> 
 +   * Integrate into 5.5, even if minor delay required 
 +   * Integrate into 5.5 only if it's not delayed, otherwise - 5.6 
 +   * Don’t integrate Optimizer+ to PHP, make avail through PECL only 
 +</doodle>
  
-  * Integrate Optimizer+ into PHP 5.5.0, allow up to 2 months delay 
-  * Integrate Optimizer+ into PHP, but don’t delay 5.5.0 for it 
-  * Don’t integrate Optimizer+ to PHP, provide it as an optional component in PECL only 
  
 ===== Changelog ===== ===== Changelog =====
Line 100: Line 120:
   * 0.75  - Added 'What is an Opcode Cache?' and 'Interaction with other extensions and plugins' sections   * 0.75  - Added 'What is an Opcode Cache?' and 'Interaction with other extensions and plugins' sections
   * 0.80  - Source code now available!  Added link   * 0.80  - Source code now available!  Added link
 +  * 0.81  - Clarify debugger & other components support is outside scope of RFC, clarify 'extreme' settings'
 +  * 0.82  - Added Naming section
 +  * 0.83  - Clarify 5.5 integration
 +  * 1.00  - Vote
 +  * 1.01  - Clarify third voting option
 +
rfc/optimizerplus.1360769690.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools