*Hashmap*, finally after a strange wakeup in the middle of the night, i researched how the array is implemented in php. I taked my last hour (or two) to read wikipedia and the php sources (wikipedia, <http://en.wikipedia.org/wiki/Hash_table> zend_hash.h<https://github.com/php/php-src/blob/master/Zend/zend_hash.h#L261> and zend_hash.c<https://github.com/php/php-src/blob/master/Zend/zend_hash.c#L909> ).
If i see this graph<http://upload.wikimedia.org/wikipedia/commons/7/7d/Hash_table_3_1_1_0_1_0_0_SP.svg>, from wikipedia, the hash isn't use to find the keys, but to find the value (the cost is O(1) at less to find the value *linked *to a key). If i see the code and particulary the following, i have the impress that the hash table is a linked list pointer which iterate on a linked list of item (call bucket<https://github.com/php/php-src/blob/master/Zend/zend_hash.h#L54>with key, value). If the cost was only O(1), the following function zend_hash_index_exists should just return value of a structure indicated by a pointer, in this case the cost seems to be O(1) to O(n) following the place of the key, for me *ulong h* is the hash : ZEND_API int zend_hash_index_exists(const HashTable *ht, ulong h) { uint nIndex; Bucket *p; IS_CONSISTENT(ht); nIndex = h & ht->nTableMask; p = ht->arBuckets[nIndex]; while (p != NULL) { if ((p->h == h) && (p->nKeyLength == 0)) { return 1; } p = p->pNext; } return 0; } Finally i'm not completly sure how php implements each array, but it seems to me that O(1) isn't right. And in fact even if a hash simplify the search a hash can't return a memory place with a data structure or a type by itself. It must be finded in a linked list before. Thanks to php to hide that :) But should we forget there pointers, structures and others c behaviors? However, the autoloading take time and was clearly showed on my profiler traces, and even if this seems not that symfony will win many speed, it will loose nothing and *gain *in the same time a *little speed* and *clarity with hermetic environnements.* * * 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 <javascript:>> > >> 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<javascript:> >> To unsubscribe from this group, send email to >> symfony-devs...@googlegroups.com <javascript:> >> 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
