Re: [PATCH v2 02/21] prefix_ref_iterator: break when we leave the prefix
- From
Stefan Beller <sbeller@google.com>
- Date
- Sep 20, 2017, 20:25 UTC
- Message-ID
- <CAGZ79kbwCAidGR3cgukdjckZVYwj+qbOikqN-e934uP1yk9Cuw@mail.gmail.com>
- In-Reply-To
- <2bb2e8ccb57eef8acbea5004167751a007a1bd2f.1505799700.git.mhagger@alum.mit.edu>
On Mon, Sep 18, 2017 at 11:22 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 34 quoted lines
> From: Jeff King <peff@peff.net>
>
> If the underlying iterator is ordered, then `prefix_ref_iterator` can
> stop as soon as it sees a refname that comes after the prefix. This
> will rarely make a big difference now, because `ref_cache_iterator`
> only iterates over the directory containing the prefix (and usually
> the prefix will span a whole directory anyway). But if *hint, hint* a
> future reference backend doesn't itself know where to stop the
> iteration, then this optimization will be a big win.
>
> Note that there is no guarantee that the underlying iterator doesn't
> include output preceding the prefix, so we have to skip over any
> unwanted references before we get to the ones that we want.
>
> Signed-off-by: Jeff King <peff@peff.net>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> refs/iterator.c | 32 +++++++++++++++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/refs/iterator.c b/refs/iterator.c
> index c475360f0a..bd35da4e62 100644
> --- a/refs/iterator.c
> +++ b/refs/iterator.c
> @@ -287,6 +287,20 @@ struct prefix_ref_iterator {
> int trim;
> };
>
> +/* Return -1, 0, 1 if refname is before, inside, or after the prefix. */
> +static int compare_prefix(const char *refname, const char *prefix)
> +{
> + while (*prefix) {
> + if (*refname != *prefix)
> + return ((unsigned char)*refname < (unsigned char)*prefix) ? -1 : +1;This looks interesting.
We get a signed char* , cast it to unsigned char* and then compare byte by byte.
The cast lead me to think that this should work for non-ASCII (e.g. ANSI?), but given that there are multi-byte characters (e.g. UTF-8) depending on your encoding used, we may not assume that in the given encoding the characters order by their byte order?
But this compare function is not to order by the natural encoding order, but it's used to detect the '0' at the end of prefix, which orders before *any* unsigned char.
We cannot enhance starts_with for this case as we'd have to invert the return value to differentiate between the prefix ordering before or after the given string.
Essentially compare_prefix wants to provide the same return value as `strncmp(refname, prefix, min(strlen(refname), strlen(prefix)));` except that it is optimized as we do not have to walk over a string multiple times (to determine length and then pass it to compare).
Feel free to ignore the rambling, I just had to sort my thoughts. The patch looks good.
Thanks, Stefan
Show 41 quoted lines
> +
> + refname++;
> + prefix++;
> + }
> +
> + return 0;
> +}
> +
> static int prefix_ref_iterator_advance(struct ref_iterator *ref_iterator)
> {
> struct prefix_ref_iterator *iter =
> @@ -294,9 +308,25 @@ static int prefix_ref_iterator_advance(struct ref_iterator *ref_iterator)
> int ok;
>
> while ((ok = ref_iterator_advance(iter->iter0)) == ITER_OK) {
> - if (!starts_with(iter->iter0->refname, iter->prefix))
> + int cmp = compare_prefix(iter->iter0->refname, iter->prefix);
> +
> + if (cmp < 0)
> continue;
>
> + if (cmp > 0) {
> + /*
> + * If the source iterator is ordered, then we
> + * can stop the iteration as soon as we see a
> + * refname that comes after the prefix:
> + */
> + if (iter->iter0->ordered) {
> + ok = ref_iterator_abort(iter->iter0);
> + break;
> + } else {
> + continue;
> + }
> + }
> +
> if (iter->trim) {
> /*
> * It is nonsense to trim off characters that
> --
> 2.14.1
>