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.
Received on 2012-05-15 13:02:49 CEST