Hello, Xdebug wasn't activated on my last bench, i used it before to profile <http://www.xdebug.org/docs/profiler>the application with kcachegrind <http://kcachegrind.sourceforge.net/html/Home.html> (win <http://sourceforge.net/projects/precompiledbin/>).
Effectivly this is interessing, you result are 4 time fast than mine. Maybe it's depends from the virtualization apply on my server, maybe the cpu is a little less agile, or the ecc ram take time to check, but 4/5 times i demand me if there is another thing, maybe your http server? What do you use? maybe have you another tip don't indicated in the docs? Anyway your benchs confirm my observations. As the system is launched on the tests before measurement, the files are in the apc cache, the array map for the apc loader is soon hashed and saved, while the classmap for composer is reread each launch. For the apc loader the cost is a hashmap access and a string allocation, a boolean test by class For the composer classmap loader should be a big hashmap allocation and 2 boolean tests, a possible string change, 2 hashmap access by class. As the composer will not be called after initialization of the bootstrap (the autoload being took in charge by the ApcClassLoader), the differences comes from the hash creation. To complete I made another benchmark with three classmap files which simulates just 2 actions: - load the class file - access a key 1000 times This test is repeated 200 times on the three differents files with differents classmaps. The average result shows sensibles differences coming from array/file size (time x 10, with a max: 20ms by request without apc). Without apc it's more or less proportionnal, with apc differences are less presents but always relevants(x3.5). The benchmark and the results are here <https://gist.github.com/4198140>. Best regards, Nicolas PS: xdebug was activated. Le samedi 1 décembre 2012 23:27:27 UTC+1, Florin Patan a écrit : > > Hey there, I've yet to read the whole thread but, from my experience, > XDebug isn't that great for measuring the performance. > I've did the following tests under a ticket for Symfony > https://github.com/symfony/symfony-standard/pull/437#issuecomment-10735469 > and it proves that Symfony2 is actually quite fast if properly used. > I'll read this and give a more proper feedback if needed, but try and see > if the tests I've did also apply to your case ;) > > > Best regards, > Florin > > On Saturday, November 24, 2012 6:15:44 AM UTC+2, Nicolas wrote: >> >> Hello, >> >> As i play all this afternoon with xdebug, i could see that* the class >> loader* take time and mainly *is called many times (~900 by request)*. >> >> As i wanted* to improve the speed of a production environnement,* i made >> tests and watch in details as the code is called. >> >> After take improvement give by the docs and finally by the command >> >>> php composer.phar dump-autoload --optimize >> >> >> I* remove *from the file *vendor/composer/autoload_classmap.php* >> produced *the tests classes* (252 on 2890, less than 1%) and run tests >> with and without there changes. The result of the tests are in a >> gist<https://gist.github.com/4137837>. >> The gain is a little more than one percent on a complex page and less >> significant on a hello world page. >> >> My personnals conclusions are the array class's map should be optimised. >> Solutions could be than : >> >> - A *arbitrary* *environnements *should be defined* in composer* to >> correspond to applications and produce specific class_loader files >> purposing *to reduce the array size* >> >> >> - The* order of calling frequencies* should impose* t*he *order in >> composer requirements* which should save it in *the order of the >> classes's map *file (vendor/composer/autoload_[env]_classmap.php)*, >> to reduce the search time* >> >> I have begin to post there solutions in a composer issue created by >> Seldaek few month ago. But as i maded tests on symfony, as i have a >> little voice in the symfony community, and i think you could think better, >> and certainly produce smarter code than me about there behaviors with >> better acuity (mostly as i see the time i spend to make this mail and >> so... and the hour it is). >> >> So good night, or have nice day, >> >> Best Regards, >> >> Nicola >> >> PS: Very thanks for all you works, symfony and composer and all the >> library become more and more nice to use. >> > -- 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 symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
