Hi All, So is anyone using ClassMapAutoloader? it seems like a better fit for high volume to reduce disk i/o when autoloading
regards, Lukas On 07.02.2011, at 18:35, Lukas Kahwe Smith wrote: > > 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
