[PHP-DEV] Re: [DRAFT] [RFC] Function autoloading
All, I have updated the RFC to include 2 new benchmarks. For normal class loading, this proposal shows at worst no change to loading time. At best, it may actually improve it because at least one zend_function_call is avoided (to spl_autoload_call). For constants and function calls, the benchmark shows that the difference is well within the margin of error for the test (considering variances of 5% to 10% were common in my running of the tests). So hopefully this will dispel any worry about performance regressions in currently defined cases. The times where performance will take a hit, is with undefined functions and constants. Today, an undefined function will fatal error, so this performance hit would be 0, as it would enable something that's not possible today. The only regression can be where autoloaders are defined, and people are relying on the legacy undefined constant behavior (which triggers an E_NOTICE). Anthony On Thu, Aug 29, 2013 at 9:23 PM, Anthony Ferrara ircmax...@gmail.comwrote: All, I have created a new draft RFC implementing function and constant autoloading in master: https://wiki.php.net/rfc/function_autoloading All feedback is welcome. Thanks Anthony
Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading
Hi The only regression can be where autoloaders are defined, and people are relying on the legacy undefined constant behavior (which triggers an E_NOTICE). that makes me think about this code : ?php namespace foo; bar(); ? What autoload should be triggered? foo\bar or bar? Both are valid isn't it? Should autoloading functions and constants be restricted to namespaced ones only? Then the BC issue you spot would disappear.
Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading
On Sat, Aug 31, 2013 at 12:13 AM, Leigh lei...@gmail.com wrote: On Aug 30, 2013 1:31 PM, Anthony Ferrara ircmax...@gmail.com wrote: For constants and function calls, the benchmark shows that the difference is well within the margin of error for the test (considering variances of 5% to 10% were common in my running of the tests). So hopefully this will dispel any worry about performance regressions in currently defined cases. The times where performance will take a hit, is with undefined functions and constants. Today, an undefined function will fatal error, so this performance hit would be 0, as it would enable something that's not possible today. I would assume there is actually potential for performance gain for functions being autoloaded in larger codebases when the *_once calls are removed that would normally load the common functions files. I just reply to this point: No. thinking we already have opcache there. so, *compiling* Functions is cheap. but if with function autoloading, *function autoloading* will execute every run. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading
On Aug 30, 2013 1:31 PM, Anthony Ferrara ircmax...@gmail.com wrote: For constants and function calls, the benchmark shows that the difference is well within the margin of error for the test (considering variances of 5% to 10% were common in my running of the tests). So hopefully this will dispel any worry about performance regressions in currently defined cases. The times where performance will take a hit, is with undefined functions and constants. Today, an undefined function will fatal error, so this performance hit would be 0, as it would enable something that's not possible today. I would assume there is actually potential for performance gain for functions being autoloaded in larger codebases when the *_once calls are removed that would normally load the common functions files.
Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 05:13:05PM +0100, Leigh wrote: On Aug 30, 2013 1:31 PM, Anthony Ferrara ircmax...@gmail.com wrote: For constants and function calls, the benchmark shows that the difference is well within the margin of error for the test (considering variances of 5% to 10% were common in my running of the tests). So hopefully this will dispel any worry about performance regressions in currently defined cases. The times where performance will take a hit, is with undefined functions and constants. Today, an undefined function will fatal error, so this performance hit would be 0, as it would enable something that's not possible today. I would assume there is actually potential for performance gain for functions being autoloaded in larger codebases when the *_once calls are removed that would normally load the common functions files. Maybe of interest: We got a performance win from exactly this at Facebook. We have some extensions in HHVM to autoload that allowed us to remove almost all our *_once calls. We have user code register an autoload map with the runtime at the beginning of most requests (an array mapping class/function names to which files to load), so we don't normally execute any user code to figure out which file needs loading. (There's various other optimizations to avoid autoload on top of that too.) I don't know enough about PHP internals to know if that approach would work as well here, though. -Jordan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading
Hi! We got a performance win from exactly this at Facebook. We have some extensions in HHVM to autoload that allowed us to remove almost all our *_once calls. But autoloading does not remove require - you still have to load the files. Only thing that can be removed is a non-loading require. Is it that frequent that it had significant performance impact (given that with opcode caching non-loading require is pretty much a couple of hash lookups)? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading
2013/8/31 Stas Malyshev smalys...@sugarcrm.com Hi! We got a performance win from exactly this at Facebook. We have some extensions in HHVM to autoload that allowed us to remove almost all our *_once calls. But autoloading does not remove require - you still have to load the files. But it removes many many 'require_once's. Only thing that can be removed is a non-loading require. Is it that frequent that it had significant performance impact (given that with opcode caching non-loading require is pretty much a couple of hash lookups)? Those, who doesn't wrap anything in classes, can see this very frequently. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 03:21:47PM -0700, Stas Malyshev wrote: Hi! We got a performance win from exactly this at Facebook. We have some extensions in HHVM to autoload that allowed us to remove almost all our *_once calls. But autoloading does not remove require - you still have to load the files. Only thing that can be removed is a non-loading require. Is it that frequent that it had significant performance impact (given that with opcode caching non-loading require is pretty much a couple of hash lookups)? For us it saved unnecessary loading requires due to transitive module dependencies, as well. I'd suspect it is unlikely to matter in nearly the same way on smaller codebases, though. -Jordan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
