[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1338350 - in /subversion/trunk/subversion: libsvn_subr/io.c libsvn_subr/skel.c libsvn_wc/wc_db.c

From: Branko Čibej <brane_at_apache.org>
Date: Tue, 15 May 2012 13:02:40 +0200

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.