seldaek / autoload-bench Goto Github PK

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

Hi,
I have been experimenting with class loader benchmarks some time myself, and came to the conclusion that the biggest source of statistic variation is probably the filesystem.

You already removed every require/include.. so what about also removing or mocking out file_exists() ?

The idea would be to measure the time for the basic algorithm (foreach loops and string operations) and then count the number of file_exists() and require. Where require is probably pointless, because this is going to be the same with each loader.

This can be done either by giving each loader a MockFilesystem, or by having a class with static methods, e.g. MockFilesystem::file_exists(). I'd say the mock object is more elegant.

There could also be a version of the MockFilesystem that actually does the file_exists(), and another one which doesn't.. this would add one level of indirection, but maybe that's ok? (because it is evenly distributed, every loader has to go through it)

The composer loader (at least the version that is being benchmarked) remembers if a class does not exist, and skips the lengthy operations next time.

This is nice, but I wonder if it is intended for the benchmark?
Composer gets very attractive numbers in the last benchmark (fail 500 classes), and mostly this is because of the repetition.
Intended or not?