[wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal

WordPress Trac noreply at wordpress.org
Sun Sep 25 06:45:52 UTC 2016


#36335: Next generation: core autoloader proposal
-----------------------------+------------------
 Reporter:  dnaber-de        |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  4.7
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+------------------

Comment (by MikeSchinkel):

 A quick follow up. I did decide to do some benchmarks.  I compared the
 current trunk with the code in the `autoloader` branch of
 [https://github.com/staylor/develop.wordpress this repo] using Query
 Monitor with inclusion of my autoloader.

 So I compared Trunk to Composer to Custom.  Up front I will say setting up
 a valid test is very challenging. All setups were running in WPLib Box
 making it likely they would be equal, but the database in all cases was
 for an initial install database with almost no records as I am not sure
 what would be a good DB to test with.

 That said I am honestly '''I am not seeing conclusive difference in
 performance between any of the three options'''. The problem is the timing
 numbers jump around all over the place and also seem dependent on how long
 since the last request of the same page, so without a scripted test any
 data I generate would likely not be valid.

 '''However, I am seeing a difference in memory usage''': Trunk was the
 worst, Custom was the best, and Composer was almost as good as Custom.
 '''''Best I can tell''''' Custom used between `5%` and `10%` less memory,
 and using Custom is about `1%` less memory than with Composer.

 The following is the `mu-plugin` I used to create the timing and then I
 just ran multiple side-by-side  terminal windows running `tail -f timing-
 log.txt` so I could easily she the results after each page load:

 {{{
 <?php

 add_action( 'shutdown', 'log_qm_stats', 11 );
 function log_qm_stats() {
     $data = QM_Collectors::get( 'overview' )->get_data();
     if ( ! empty( $data['time_taken'] ) ) {
         file_put_contents(
             ABSPATH . 'timing-log.txt',
             sprintf(
                 "'%s', %s, %s, '%s', '%s'\n",
                 defined( 'USE_COMPOSER_AUTOLOADER' ) &&
 USE_COMPOSER_AUTOLOADER
                     ? 'composer'
                     : ( 'wptrunk.dev' === $_SERVER[ 'HTTP_HOST' ]
                         ? 'trunk___'
                         : 'custom__'
                     ),
                 $data['memory_usage'],
                 $data['time_taken'],
                 $_SERVER['REQUEST_URI'],
                 isset( $_REQUEST ) ? str_replace( "'", "\\'",
 http_build_query( $_REQUEST ) ) : 'null'
             ),
             FILE_APPEND
         );
     }
 }
 }}}

 That said, my methodology could very easily have been flawed and I would
 be happy if anyone would like to validate it.

 One this is that Query Monitor does not keep track of data for certain
 Customizer page loads which I had expected might show a difference, but as
 is I could not verify.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36335#comment:220>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list