Changes have been made in Git for this ticket:

Add Autoloader_Cache library to cache class maps from the Autoloader 
package (Request #10396).

  3 files changed, 609 insertions(+), 0 deletions(-)
http://git.horde.org/horde-git/-/commit/351190d0cd4e7ae85690fab2b861b6263cda23d6

One solution could be to make this a separate non-dependant package, 
and make the package class decorating the original default autoloader. 
Admins would have to explicitly install this package to enable 
autoloader caching, thus we won't need any configuration to disable 
it, and we can make it the admin's job to take care of cache cleaning 
if necessary. A small script could help with that.
In Horde, we would check if this package's class file exist, and load 
that, otherwise fall back to the default autoloader.
Does anybody see any issues with this approach?

http://git.horde.org/horde-git/-/commit/192c56b7c64ad886b25ae4fb250eb853e310ff01

What about providing a *very* basic temp file fallback if none of 
these caching backends are available?  (e.g. using sys_get_temp_dir(), 
file_get_contents(), and file_put_contents()).

POC, works pretty well, still needs a way to invalidate the cache.

For most page requests, loading all the PHP files through the 
autoloader is the most expensive operation now. The actual file 
loading can be improved by using a bytecode cache. Even more expensive 
is the class name to file path mapping though, especially the regular 
expressions.
The idea is to store this map directly, i.e. without using Horde_Cache 
for obvious reasons, in a cache. Since users interested in speeding up 
the file loading are using APC or similar anyway, the autoloader 
should use such a bytecode cache for caching the map too, if the 
extension supports arbitrary caching.