Consider creating cli script for class path cache generation after deploy

[Zyava]

See FS classmap generator from m2: https://github.com/magento/magento2/blob/master/dev/tools/classmap/fs_generator.php. The idea is to not cache on the fly but just generate class path cache one time after the deploy. I don't think it is common when new classes are created on production after deploy.

[fbrnc]

This will result in a huge class map containing all classes, right? But in most cases only a remarkably smaller portion of all classes (especially in lib) are actually being used. The resulting classmap might be unnecessary big eating up memory and making accessing it slower.

What would be the benefit of a pre-generated classmap?

[Zyava]

Benefits are evident:

• No file name lookup over the include path at all, just file include, with opcache it means no disk access at all
• With APC/ZendPtimizer generated php file is in opcache, so again no disk access

Regarding memory, we can try to hash class name with crc32 and use SplFixedArray (http://php.net/manual/en/class.splfixedarray.php) or judy arrays (http://www.php.net/manual/en/class.judy.php). Memory footprint of judy array is very small, especially if we go with crc32 and of Judy::INT_TO_MIXED mode (crc32($fileName) => $path). I believe it would be around 5MB, but some benchmarks are needed of course.

Becuase there is no serialization support in judy arrays at the moment it can be used only with opcache. In non-opcache mode we can try to utilize crc32 + SplFixedArray (if memory footprint isn't too big) or fallback to current implementation.

However I'm not sure there is any sense to consider non-opcache mode at all. All modern websites use opcache. And since judy arrays need additional extension, why not install ZendOptimizer or APC too?