Fixed Add-on Composer support seems inefficient

Affected version
2.2.4

Kirby

Well-known member
If an Add-on does have a composer autoloader directory defined, XenForo will check if that directory and installed.json within that path does exist in XF\ComposerAutoload::__csonstruct()

PHP:
if (!file_exists($pathPrefix) || !file_exists($pathPrefix . \XF::$DS . 'installed.json'))
{
    throw new \InvalidArgumentException(
        'Composer Autoload path (' . htmlspecialchars($this->getPathForError($pathPrefix)) . ') does not appear to be a valid composer directory.'
    );
}

This check seems superflous - no matter if the file or its parent directory does not exist, the result will always be the same exception. so the check on $pathPrefix could be removed completely saving one stat.

Furthermore, methods autoload* will also check for existence of files prior to including them which again does result in stat calls.

So all in all that acculumates to 6 stat calls on every page of which 5 will always result in true (unless there is a fatal error).
This seems pretty inefficient, especially considering that autoload_files.php might not even exist.

A better approach would be to read the data when rebuilding addons.composer and just use that at runtime instead of continously checking/including files.
 

Chris D

XenForo developer
Staff member
We've fixed this for the next release, 2.2.6.

We now have a grand total of... zero stat checks during runtime!

We're doing all of the file_exists checks at save time (when the add-on caches are rebuilt) and storing them in a new cache format that tracks the existence of each autoload_*.php file and attempts to load the ones that are available.

Overall the behaviour is roughly identical without the repeated stat checks and the errors being logged/thrown in a different place.
 
Top