A patch[1] was recently merged which adjusts the changes required when adding or removing classes from mediawiki core.
Rather than manually adjusting the map from classname to filename in includes/AutoLoad.php developers now need only run the maintenance/generateLocalAutoload.php script. This script will scan mediawiki core and output an equivalent map from classname => filename to autoload.php in the root of the repository.
Erik B.
That's a lot of string concatenation in the new file, and I wonder if the many array assignments are less efficient than just assigning one large array.
On Thu, Nov 13, 2014 at 11:24 PM, Erik Bernhardson < ebernhardson@wikimedia.org> wrote:
A patch[1] was recently merged which adjusts the changes required when adding or removing classes from mediawiki core.
Rather than manually adjusting the map from classname to filename in includes/AutoLoad.php developers now need only run the maintenance/generateLocalAutoload.php script. This script will scan mediawiki core and output an equivalent map from classname => filename to autoload.php in the root of the repository.
Erik B.
[1] https://gerrit.wikimedia.org/r/163304 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
For zend >= 5.5 constant string concatenation is "free"[1] with the optimizer enabled. Essentially if both sides of the concat operation are constants its resolved before caching the opcodes. I don't know specifically but i would imagine hhvm does similar. We are running 5.3 in prod, I'm willing to change this if desired. Note that if we do not do the "free" concatenation here then the actual autoloader calls will do non-free concatenation joining $IP to the path for every class it loads. This is certainly less concatenations, but it makes it harder to judge which is more performant on 5.3.x.
In a quick test with zend 5.5.9 loading a 1000 item array 100 times gives ~140ms assigning each array key independently and ~85ms assigning as a complete array. With HHVM i see ~23ms assigning each array key independently, and ~10ms as a complete array. prepending __DIR__ appears to make no difference in runtime.
Followup patch retaining string concatenation, but switching to a single array literal instead of per-key assignment: https://gerrit.wikimedia.org/r/173326
Erik B.
[1] https://github.com/php/php-src/blob/master/ext/opcache/Optimizer/pass1_5.c#L...
On Fri, Nov 14, 2014 at 7:06 AM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org
wrote:
That's a lot of string concatenation in the new file, and I wonder if the many array assignments are less efficient than just assigning one large array.
On Thu, Nov 13, 2014 at 11:24 PM, Erik Bernhardson < ebernhardson@wikimedia.org> wrote:
A patch[1] was recently merged which adjusts the changes required when adding or removing classes from mediawiki core.
Rather than manually adjusting the map from classname to filename in includes/AutoLoad.php developers now need only run the maintenance/generateLocalAutoload.php script. This script will scan mediawiki core and output an equivalent map from classname => filename to autoload.php in the root of the repository.
Erik B.
[1] https://gerrit.wikimedia.org/r/163304 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org