Re: [GENERAL] Re : Solaris Performance - Profiling (Solved)
От | mlw |
---|---|
Тема | Re: [GENERAL] Re : Solaris Performance - Profiling (Solved) |
Дата | |
Msg-id | 3CAB2CB2.1745AC2F@mohawksoft.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] Re : Solaris Performance - Profiling (Solved) (Justin Clift <justin@postgresql.org>) |
Список | pgsql-hackers |
Doug McNaught wrote: > I think most vendors do a pretty good job. Don't forget, optimizing a > routine like that depends a lot on the cache size and behavior of the > CPU and other architecture-dependent stuff. >> qsort() is a great sort for very random data, when data is mostly in the >> correct order, it is very bad. Perhaps replacing it with an alternate sort >> would improve performance in general. > Actually, the C standard says nothing about what algorithm should be > used for qsort(); it's simply supposed to be a fast in-memory sort. > The qsort() name is just a historical artifact. Perhaps so, but maybe that is the issue with Solaris, it actually may use qsort algorithm. I am not too sure how one would optimize the qsort() API on a platform basis. The sorting algorithm uses a callback function, this precludes any meaningful optimization. Yea, you can play with memory page sizes, and so on, but you still have to do a function call for some multiple of the number of elements in the array.
В списке pgsql-hackers по дате отправления: