On 15.05.2012 12:56, Stefan Sperling wrote: > On Tue, May 15, 2012 at 05:38:41AM -0400, Greg Stein wrote: >> If Bert can somehow demonstrate how a qsort() is troublesome, then ... >> sure. And if he can somehow show that the cpu clocks are more >> important than the long-term ability of our community to maintain svn >> against the coupling of "skel prop parsing" and "svn status output"... >> then, wow. That would be an amazing demonstration. > I'd also like to note that svn_sort__hash() does not invoke qsort() > if hash keys happen to be returned in sorted order. It only performs > a linear scan in that case. > > So... a compromise could be to keep using svn_hash__make(), with a comment > that explains that we'd like to our own faster and stable hash function, > in particular because stable key ordering is more desirable for our use case > than random key ordering.
That doesn't really make much sense. Only the test suite is intersted in /stable/ key ordering, and that's just because the test result comparison functions require it. Users will not care about stable output unless it's sorted. On the subject of hash functions, I doubt you can go much faster than what APR already has, except for saving the few bytes of the randomizer added to the key. -- Brane
