Re: com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c
Zend/zend_hash.h Zend/zend_ini.c Zend/zend_llist.c Zend/zend_qsort.c Zend/zend_qsort.h Zend/zend_sort.c Zend/zend_sort.h Zend/zend_ts_hash.c
Zend/zend_types.h configure.in ext/ereg/ereg.c ext/intl/collator/collator_sort.c ext/phar/dirstream.c ext/phar/phar_internal.h ext/standard/array.c
ext/standard/info.c ex

On Sat, Jan 17, 2015 at 6:24 AM, Xinchen Hui <laruence@php.net> wrote: > Hey: > > On Sat, Jan 17, 2015 at 1:16 PM, Xinchen Hui <laruence@php.net> wrote: >> but okey, I agree we need write some note(actually I noted in UPGRADE >> of we are using hybrid sorting algo now).. >> >> but what kindof note I mean how details it should be? I am not a >> native english speaker, could anyone here to help me to write that ? > and to explained my concern . that is, the 16 is my picked number, I > did some benches, then use 16.. > > but maybe we could change that later... > > like std::sort doesn't use a fixed limit, but choose 10 or 30 > according the how heavy the swap fucntion is.. As I agree that such micro optimization (for an app) are a good thing and now is the right time to do it, as Rasmus said we have to be careful. I am not saying we should revert it but we may be open about it. Once more users will actually test master/7, we may have more bug reports about such changes, giving us a better view on the actual impact of these changes with real world applications. For some of them I suspect we may actually drop the optimization as the impact on BC will be significantly bigger than the performance gains. Wait and see :) -- Pierre @pierrejoye | http://www.libgd.org