Forked autoload-bench, interesting predictor techniques, PSR-4

[donquixote]

Hi Jordi!
I openend a number of pull requests in the last days, I don't know if you are interested.
But finally I changed so much on it that it is probably too much to merge back into yours..
https://github.com/donquixote/autoload-bench

I added some new loaders with different predictor techniques, including some that support PSR-4 and PSR-0.
I thought some of this might be interesting for you ..

Thanks for your work on this!
Andreas

[Seldaek]

If you like I can also just give you access to this repo if you'd like to make changes. Everything seemed reasonable until now, and frankly I don't have so much time to look into this these days. I'd be happy if someone finds a better algorithm so we can put that in composer, but that needs to be dead simple and not rely on platform specific features (symlinks, classmap, apc all are options for optimizations but shouldn't be the default autoload method).

[donquixote]

Hi,
In the fork I made some changes which take away stuff from the original autoload-bench.

E.g. I no longer measure file_exists(), I only count it (and the boring result: they all have the same number).
I also no longer measure the setup time, and don't generate any setup php files.

Thus, it might be better to let the forked autoload-bench live as standalone, while keeping the old one. Both have a slightly different focus of what they do.

[donquixote]

This being said: How can I continue to do PRs to your stuff, if my own master is a fork that I don't intend to merge back?
Maybe it would indeed be the best if I have access..

Or I could add some of the file_exists() and setup and file generation stuff back into my version, and make it optional. E.g. there would be one prepare() method with file generation, and another without.

[Seldaek]

You can just create branches in your repo based on this one: git checkout -b patch-branch Seldaek/master will do that, assuming you have a Seldaek upstream.

Anyway I don't think the file_exists checks count should be the same for every autoloader so I think you got something weird going on :) A PSR-0/composer style one will do more checks if many prefixes are matching one same class, and a classmap one should never do any file system check IMO.

[donquixote]

Anyway I don't think the file_exists checks count should be the same for every autoloader so I think you got something weird going on :) A PSR-0/composer style one will do more checks if many prefixes are matching one same class, and a classmap one should never do any file system check IMO.

Absolutely, I simplified my statement :)

Classmap and APC don't do file_exists(). But we don't really need autoload-bench to tell us that. We already know they are faster than regular PSR-0 lookups.

The PSR-0 ones would do one file_exists() per matching prefix. But the way the test scenarios are built, the first matching prefix is always the right one. Which is probably the common case to optimize for. So, quite boring there.