On 07.02.2011, at 16:18, Fabien Potencier wrote: > On 2/7/11 10:37 AM, Sven Paulus wrote: >> It would be great if there was a (optional?) way to use the universal >> class loader without calling file_exists() at all: >> >> If you are running in a high volume environment, you are likely using >> APC with apc.stat = 0 (see >> http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat) so that >> once all the classes are cached in memory, the file system layer doesn't >> need to get involved any more (no stat(2) calls needed at all). >> >> However if the universal class loader uses file_exists() every time >> before doing a require() the main purpose of this optimization is gone, >> because there still will be a stat(2) system call every time a class is >> accessed for the first time within a request. >> >> Having an option to disable file_exists() and use an unambiguous mapping >> from class name to file name would take a lot of pressure from the IO >> layer (which is e.g. especially important if you're running the web farm >> from a NFSv3 based filer which doesn't allow client side caching). > > We really have 3 autoloading strategies in Symfony2 (used in this order): > > * The bootstrap.php/classes.php file where the major PHP files are "compiled" > into one big file (no autoloading necessary for these files) > * The class map class loader (a map as we had in symfony1 where > you/extensions can add as many classes as you want) > * The universal class loader
so you are saying that the class map class loader is what apc.stat=0 setups should use? even still i think the approach i send has some merit in general. with my solution i do use the ugly @, but since i then use stream resolve include path to determine if a "false" was caused by a missing file or by a parse error and in case of a parse error still require, the net effect should be the same: parse errors are seen, missing files are skipped and the next NS dir is attempted and existing files cause it to return. i only briefly tested it and with that change i didnt see any immediately visible breakage. regards, Lukas Kahwe Smith [email protected] -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
