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

Re: svn commit: r1483532 - in /subversion/trunk/subversion: include/ libsvn_client/ libsvn_fs_base/ libsvn_fs_fs/ libsvn_ra/ libsvn_ra_local/ libsvn_ra_svn/ libsvn_repos/ libsvn_subr/ libsvn_wc/ mod_dav_svn/ svndumpfilter/ svnmucc/ svnrdump/ svnserve/ svn

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Fri, 17 May 2013 12:06:27 +0200

On Fri, May 17, 2013 at 12:23 AM, Julian Foad <julianfoad_at_btopenworld.com>wrote:

> Bert Huijben wrote:
> > Ivan Zhakov wrote:
> >>> Author: stefan2
> >>> URL: http://svn.apache.org/r1483532
> >>> Log:
> >>> We frequently use property name constants in conjunction with hash
> >>> containers. Provide new wrappers around apr_hash_get and apr_hash_set
> >>> that accept such string constants and statically determine their size.
> >>> That minimizes the hash access costs.
> >>>
> >>> Mass change hash get and set calls for SVN_PROP_* constants.
> >>
> >> Is the performance gain costs code complexity? Please understand my
> >> correctly: it's great improve Subversion speed. I just don't like
> >> the idea getting code more complicated to win just several cycles.
> >
> > I can see this change making some difference when used in a tight loop
> in fsfs,
> > but in almost every case updated here it is a single call per 'svn' (or
> > other tool) invocation and I don't think the added complexity and the
> risk
> > of accidentally applying it to a pointer in the future makes sense here.
> The
> > cost of a strlen on a string of a few characters certainly isn't that
> high.
> >
> > The IO overhead is so much larger that global changes like this in the
> higher
> > layers don't make any sense to me.
> A safer and simpler design to achieve the same goal as this could be:
> #define svn_hash_gets(ht, key) \
> svn__internal_hash_get(ht, key, strlen(key))
> which works because the compiler can then optimize out the "strlen" when
> it is safe and possible to do so.

Excellent idea. I just tried it and at least GCC is clever enough
to do that optimization. I'll commit that change tonight.

-- Stefan^2.

*Join one of our free daily demo sessions on* *Scaling Subversion for the
Enterprise <http://www.wandisco.com/training/webinars>*
Received on 2013-05-17 12:07:06 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.