Re: [GENERAL] Re : Solaris Performance - Profiling (Solved)
От | Doug McNaught |
---|---|
Тема | Re: [GENERAL] Re : Solaris Performance - Profiling (Solved) |
Дата | |
Msg-id | m3d6xg69k0.fsf@varsoon.wireboard.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] Re : Solaris Performance - Profiling (Solved) (Justin Clift <justin@postgresql.org>) |
Ответы |
Re: [GENERAL] Re : Solaris Performance - Profiling (Solved)
|
Список | pgsql-hackers |
mlw <markw@mohawksoft.com> writes: > > Because qsort() is *supposed* to be optimized by the vendor for their > > platform, perhaps even written in assembler. It makes sense to trust > > the vendor except when their implementation is provably pessimized. > > Perhaps *supposed* to be optimized, but, in reality, are they? Is it a > realistic expectation? 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. -Doug -- Doug McNaught Wireboard Industries http://www.wireboard.com/ Custom software development, systems and network consulting. Java PostgreSQL Enhydra Python Zope Perl Apache LinuxBSD...
В списке pgsql-hackers по дате отправления: