rfc:function_autoloading

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
Next revisionBoth sides next revision
rfc:function_autoloading [2013/08/30 12:19] – add performance section ircmaxellrfc:function_autoloading [2013/09/03 12:28] – Withdrawn ircmaxell
Line 4: Line 4:
   * Date: 2013-08-29   * Date: 2013-08-29
   * Author: Anthony Ferrara <ircmaxell@php.net>   * Author: Anthony Ferrara <ircmaxell@php.net>
-  * Status: Draft+  * Status: Withdrawn
   * First Published at: http://wiki.php.net/rfc/function_autoloading   * First Published at: http://wiki.php.net/rfc/function_autoloading
  
Line 186: Line 186:
   * Proposal: average 0.000218 Seconds to call 1000 functions   * Proposal: average 0.000218 Seconds to call 1000 functions
  
-Therefore, there is no performance regression to normal function calls (defined functions).+ 
 +Therefore, there is no performance regression to normal function calls (defined functions). The margin of error for this test was on the order of +-0.00004 seconds. 
 + 
 +=== Constants === 
 + 
 +1000 constants were generated and placed in a single file. The following test script was used to test if there was any change to function call time for a defined function: 
 + 
 +<file php benchmark_constants.php> 
 +<?php 
 +require_once 'constants.php'; 
 + 
 +$start = microtime(true); 
 +for ($i = 0; $i < 1000; $i++) { 
 +        $name = 'test' . $i; 
 +        constant($name); 
 +} 
 +$end = microtime(true); 
 + 
 +echo "Completed in " . ($end - $start) . " seconds\n"; 
 +?> 
 +</file> 
 + 
 +  * Master: average 0.000228 Seconds to call 1000 constants 
 +  * Proposal: average 0.000221 Seconds to call 1000 constants 
 + 
 +Therefore, there is no performance regression to normal constant lookups (defined constants).
  
 ==== Userland Backwards Compatibility ==== ==== Userland Backwards Compatibility ====
Line 236: Line 261:
  
 It is more of a "why not" question. Supporting multiple types of autoloaded constructs in a single callback can result in a more flexible architecture for end users. It is more of a "why not" question. Supporting multiple types of autoloaded constructs in a single callback can result in a more flexible architecture for end users.
 +
 +==== What Filename Conventions Does This Support? ====
 +
 +None, and all. This proposal presently implements no type of file loading handler.
 +
 +The only thing that is implemented is the ability to register a callback to attempt to load a function or constant (or class) when it is missing. How the callback maps structures to files is outside of the scope of this RFC.
 +
 +==== Doesn't This Complicate The Engine? ====
 +
 +Nope! The reason is that the current autoloading mechanism for classes is extremely fragile as is.
 +
 +For example, the implementation hinges on a global variable which sets the php-level callback to call on autoload. This requires setting up a //zend_fcall_info// struct, and a //zend_fcall_info_cache// struct, as well as dispatching a function internally to autoload. [[https://github.com/php/php-src/blob/9e17094cf4dde60432569246a9a59e48783530bb/Zend/zend_execute_API.c#L1066|The Current Implementation]].
 +
 +The implementation of //spl_autoload_call// and //spl_autoload_register// are also extremely complicated. [[https://github.com/php/php-src/blob/9e17094cf4dde60432569246a9a59e48783530bb/ext/spl/php_spl.c#L466|The current SPL implementation]].
 +
 +This refactor cleans both of these pieces up significantly.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
rfc/function_autoloading.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools