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

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. But we also run svn_sort__hash() on the list of
dirents to guarantee sorted output. This will usually not invoke qsort(),
just scan the list.

That way, we have a clear separation of concerns, and guaranteed sorted
output, and no unnecessary qsort() calls. And hopefully everyone is happy.
Received on 2012-05-15 12:57:03 CEST