On Fri, May 17, 2013 at 12:23 AM, Julian Foad <julianf...@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>* * *
