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

Re: svn commit: r1507044 -

From: Ben Reser <ben_at_reser.org>
Date: Thu, 25 Jul 2013 19:52:43 -0700

On Thu, Jul 25, 2013 at 5:26 PM, Ben Reser <ben_at_reser.org> wrote:
> There are far fewer cases where svn_hash_gets() results in extra work.
> At first I thought it might not be worth fixing it since you have to
> turn it into a function. But then I ran into the cases in libsvn_wc
> and libsvn_delta and I think we should fix it as well.

So I'm not sure what to do about the svn_hash_gets() case. If I
convert it to a function it's no longer optimal for literal strings
(unless the compiler is inlining it, which it probably won't be
because it's an external function). In which case I might as well
just put it back as:
#define svn_hash_gets apr_hash_get(ht, key, APR_HASH_KEY_STRING, val)

If we don't change it then we need to change all the callers to be
careful about not putting expressions that would be an issue when
evaluated twice, which is almost certainly going to be done wrong at
some point in the future.

If we do change it then we'll probably end up using apr_hash_get()
with literal strings because we end up with more optimal code in those
cases. The upside here is that even if we end up using svn_hash_get()
where it would be less optimal to do so, it probably won't be as bad
as using svn_hash_gets() as it exists now with a function call as the
key expression.

Anyone else got some clever idea on how to fix it that I haven't thought of?
Received on 2013-07-26 04:53:23 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.