2012/11/29 Nicolas <nicolas.demar...@gmail.com> > For me a *sort($test)*, where $test is an array isn't a O(1) complexity > sort even no loop are presents, are you agree? >
Why do you want to sort it? As soon as the map is generated you don't need to sort it again (in fact you don't need to sort it _at all_. It's a map). Even further, as far as I remember the sorted map is only a side effect on how composer allocates the files and classes: It iterates over the directories and let the underlying FS decide how it returns the entries. The order is completely unrelated. > > For the classmap, the `search` not directly open the good key, i think > this is more a 0(n) for the worst case and 0(1) for the better case even if > this work isn't made in php and in fact as it exists an isset before, the > work is maybe made two times 0(2n) (but php has maybe a buffer, i hope). The classmap created by composer uses an array, an array is internally a hashmap and this means, that accessing a key is a single-instruction-operation (the access itself), but no "search" is required. Read about hashmaps for further information. Btw: O(n) = O(2n) .... > > Le mercredi 28 novembre 2012 17:05:15 UTC+1, Sebastian Krebs a écrit : >> >> As long as a classmap is a map, it's a hashmap and therefore the access >> is usually O(1), meaning: Doesn't care, where the corresponding class >> appears within the list. >> >> >> 2012/11/28 Nicolas <nicolas....@gmail.com> >> >>> Tests maded with apc, and even with apc the class isn't load if the file >>> isn't load, so apc don't avoid the autoload mecanismus. >>> >>> For the differences beetween dev and prod environnement, i think the >>> number of classes isn't the only point, the order is to a problem, as >>> symfony is at the end of the class map (the order is alphabetical), so each >>> symfony class take more than 1500 comparisons strings to just load the >>> classes at every requests. >>> >>> Le mercredi 28 novembre 2012 06:46:55 UTC+1, Cameron Junge a écrit : >>> >>>> Were the tests performed with & without APC? APC will load the file >>>> straight from memory in a compiled form, so should help speed things up if >>>> the original tests were performed without it. Most production environments >>>> use a cache. >>>> >>>> Building an optimized classmap for each environment would probably only >>>> alter a small number of classes, so not sure what benefit there is in >>>> having multiple versions. For example, the difference between dev & >>>> production on one of my projects would probably be a few 10s or so >>>> classes... and some of them will be the automatic exchange of a debug class >>>> & the original class. >>>> >>>> Cameron >>>> >>>> On Saturday, November 24, 2012 5:15:44 PM UTC+13, 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 symfon...@googlegroups.com >>> >>> To unsubscribe from this group, send email to >>> symfony-devs...@**googlegroups.com >>> >>> For more options, visit this group at >>> http://groups.google.com/**group/symfony-devs?hl=en<http://groups.google.com/group/symfony-devs?hl=en> >>> >> >> >> >> -- >> github.com/KingCrunch >> >> -- > 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 > -- github.com/KingCrunch -- 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
