Uploaded image for project: 'phpBB3'
  1. phpBB3
  2. PHPBB3-12051

Optimise Composer Autoloader on Build

    Details

    • Type: Improvement
    • Status: Unverified Fix
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 3.1.0-dev
    • Fix Version/s: 3.1.0-RC3
    • Component/s: Build System
    • Labels:
      None

      Description

      Instead of just installing vendors using `php composer.phar install` when building final packages we should use the `--optimize-autoloader` flag as it will turn the PSR-0 autoloading into a static classmap of the libraries we use through composer, improving performance (a bit).

      1. t1
        1 kB
        JoshyPHP
      2. t1p
        1 kB
        JoshyPHP
      3. t2
        1 kB
        JoshyPHP
      4. t2p
        1 kB
        JoshyPHP
      5. t3
        1 kB
        JoshyPHP
      6. t3p
        1 kB
        JoshyPHP

        Issue Links

          Activity

          Hide
          JoshyPHP JoshyPHP added a comment -

          I have run some benchmarks on develop, straight from GitHub's zip and running on a clean db. Used ab with no concurrency, didn't restart the server between runs, primed the caches with a test run before saving the results. PHP 5.5.6, /tmp is tmpfs.

          I have tested three configurations:
          1. default
          2. with -o
          3. with -o plus using Composer's PSR-0 autoloader for the phpbb namespace and without creating $phpbb_class_loader

          With Opcache, the results in requests per second go like this: 68.35, 71.37, 77.28.
          Without Opcache: 13.73, 13.42, 13.40.

          With an opcode cache, using a static classmap measurably improves the performance. Removing phpBB's own class loader improves it further.
          Without an opcode cache, the time spent parsing the classmap clearly negates its benefits. Making the classmap bigger negates the benefits of removing phpBB's own class loader.

          I'm attaching ab's output for each configuration as t1/t2/t3. "p" is for runs without Opcache.

          Show
          JoshyPHP JoshyPHP added a comment - I have run some benchmarks on develop, straight from GitHub's zip and running on a clean db. Used ab with no concurrency, didn't restart the server between runs, primed the caches with a test run before saving the results. PHP 5.5.6, /tmp is tmpfs. I have tested three configurations: 1. default 2. with -o 3. with -o plus using Composer's PSR-0 autoloader for the phpbb namespace and without creating $phpbb_class_loader With Opcache, the results in requests per second go like this: 68.35, 71.37, 77.28. Without Opcache: 13.73, 13.42, 13.40. With an opcode cache, using a static classmap measurably improves the performance. Removing phpBB's own class loader improves it further. Without an opcode cache, the time spent parsing the classmap clearly negates its benefits. Making the classmap bigger negates the benefits of removing phpBB's own class loader. I'm attaching ab's output for each configuration as t1/t2/t3. "p" is for runs without Opcache.
          Hide
          MichaelC Michael Cullum added a comment -

          Our autoloading isn't PSR-0 compatible (underscores). It's also interesting it's slower, I've only ever seen it be faster.

          Show
          MichaelC Michael Cullum added a comment - Our autoloading isn't PSR-0 compatible (underscores). It's also interesting it's slower, I've only ever seen it be faster.
          Hide
          JoshyPHP JoshyPHP added a comment -

          I didn't know that PSR-0 mandated use underscores as separators in namespaced classes. In that case you can use an explicit classmap.

          Show
          JoshyPHP JoshyPHP added a comment - I didn't know that PSR-0 mandated use underscores as separators in namespaced classes. In that case you can use an explicit classmap .

            People

            • Assignee:
              nicofuma nicofuma
              Reporter:
              MichaelC Michael Cullum
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development