[Solved] Is it possible to tell the Autoloader to ignore a folder?

businessdad

Hi all,
I'm working on my next plugin and, due to its use of 3rd party libraries, it contains a folder with about 65 files. This folder will never contain anything for Vanilla, but it seems scanned anyway by the Autoloader, which slows things down quite a bit. I was therefore wondering if there's a way to tell the AL to stay out of it.
Thanks in advance for the answers.

peregrine

@todd will surely give you the best answer.

But I think a kluge would be

if your plugin was called Sample and you put all the usual files in Sample
and put all the 3rd party libraries in SampleAddition. As long as you called what you needed with the Sample plugin with paths to SampleAddition. I don't think main vanilla would pick it up in the autoloader (just a theory).

UnderDog

Also... take a look at the location of the Markdown library files...

I don't think you have that folder with 65 files in the right location :-)

businessdad

@UnderDog Definitely not, I should probably put it into vendors folder. However, I found out that Autoloader is not "guilty", the slowness is somewhere else. Now I need to find a good profiling tool (xdebug doesn't seem to be keeping track of everything the call to some of my functions don't show up). Thanks for the answers so far.

businessdad

Problem solved! I'm using a 3rd party library which provides its own Autoloader. The slowdown was due to the fact that, before the library's Autoloader kicked in, Vanilla's Autoloader wanted to do its job.

It didn't matter if I put the library in vendors or inside the plugin, as the library itself relies on autoloading and this means "bothering" Vanilla. I found two solutions to this issue:

1- Unregistering Vanilla Autoloader before calling Library's initialization routine and registering it again immediately after. This initialization occurs only once, and that's the only place where the Library needs to load its own files. Such initialization has nothing to do with Vanilla, it doesn't trigger any event and it's completely encapsulated. Therefore, the unregister/register approach is safe, although unorthodox.
2- Modify the Library so that its Autoloader function would be prepended to the Autoloaders List and, therefore, would run before Vanilla's one. In case someone wonders if this solution would produce the original issue in reverse (i.e. any other plugin would now be slower because of the new Autoloader in the chain), there is no risk. Library's Autoloader doesn't do folder scans, buffering or anything, it simply keeps an array of Class => File name entries. Should it receive a request for a class it doesn't have, all it would cost in terms of execution would be an isset() against the array, which would be negligible.

Personally, I'm using the second solution, simply because I don't like unregistering core stuff without being 100% sure that I'm able to register it back. It's true that an Exception would interrupt the execution anyway, but I find it a bit "dirtier". The only real risk, if we really want to look for one, is that someone implements a class with the exact same name of one registered by Library's Autoloader. However, I think this could be an issue even with Vanilla's Autoloader, as there is no absolute guarantee that a plugin won't implement a class whose name has already been used.

I hope this can help other people in the future.