On Mon, Feb 24, 2025 at 09:08:40PM +0800, shejialuo wrote:
> On Wed, Feb 19, 2025 at 02:23:37PM +0100, Patrick Steinhardt wrote:
> > Reftable iterators need to be scrapped after they have either been
> > exhausted or aren't useful to the caller anymore, and it is explicitly
> > not possible to reuse them for iterations. But enabling for reuse of
> > iterators may allow us to tune them by reusing internal state of an
> > iterator. The reftable iterators for example can already be reused
> > internally, but we're not able to expose this to any users outside of
> > the reftable backend.
> >
>
> Out of curiosity, is there any benefits for reusing iterators for files
> backend?
We see a small improvement there due to reduced allocation churn, but
overall the benefit is more limited there, as shown by the last commit
in this series where we start to reuse iterators. The refactorings may
unlock further optimization potential by reusing more of the iterators'
state, but I haven't checked for the "files" backend.
> > Introduce a new `.seek` function in the ref iterator vtable that allows
> > callers to re-seek an iterator. It is expected to be functionally the
>
> It's a bit strange that we use "re-seek". I think we just want to see an
> iterator. Isn't it? Don't worth a reroll.
Well, it's really only relevant in the case where we want to seek on an
iterator multiple times because we already seek when creating the
iterator. I'll reformulate this slightly.
> > @@ -368,6 +381,16 @@ static int prefix_ref_iterator_advance(struct ref_iterator *ref_iterator)
> > return ok;
> > }
> >
> > +static int prefix_ref_iterator_seek(struct ref_iterator *ref_iterator,
> > + const char *prefix)
> > +{
> > + struct prefix_ref_iterator *iter =
> > + (struct prefix_ref_iterator *)ref_iterator;
> > + free(iter->prefix);
>
> Here, we need to free the "iter->prefix". We don't know whether the
> caller would call `prefix_ref_iterator_seek` many times for the same ref
> iterator. So, we need to restore the state/context.
>
> I want to ask a question here, why don't we care about "trim" parameter
> which is declared in the "prefix_ref_iterator_begin"? From my
> understanding, we may want to reuse "trim" state in the original state.
> So, when we want to reuse iterator, we only consider about the "prefix"
> but leave the other stats the same. Is my understanding correct?
Yeah, it's correct. I couldn't find a usecase for also adjusting "trim"
when seeking multiple times, so I didn't introduce this functionality.
Let me mention this in the commit message.
> > + iter->prefix = xstrdup_or_null(prefix);
> > + return ref_iterator_seek(iter->iter0, prefix);
> > +}
> > +
>
> > diff --git a/refs/refs-internal.h b/refs/refs-internal.h
> > index 74e2c03cef1..3f6d43110b7 100644
> > --- a/refs/refs-internal.h
> > +++ b/refs/refs-internal.h
> > @@ -327,6 +327,21 @@ struct ref_iterator {
> > */
> > int ref_iterator_advance(struct ref_iterator *ref_iterator);
> >
> > +/*
> > + * Seek the iterator to the first reference with the given prefix.
> > + * The prefix is matched as a literal string, without regard for path
> > + * separators. If prefix is NULL or the empty string, seek the iterator to the
> > + * first reference again.
> > + *
> > + * This function is expected to behave as if a new ref iterator with the same
> > + * prefix had been created, but allows reuse of iterators and thus may allow
> > + * the backend to optimize.
>
> I somehow think we may emphasis that we want to reuse some internal
> states of the ref iterator except the prefix. However, I am not sure.
> Just think about this.
Yup, I'll improve the comment.
> > @@ -445,6 +460,13 @@ void base_ref_iterator_init(struct ref_iterator *iter,
> > */
> > typedef int ref_iterator_advance_fn(struct ref_iterator *ref_iterator);
> >
> > +/*
> > + * Seek the iterator to the first reference matching the given prefix. Should
>
> Maybe which should?
>
> > + * behave the same as if a new iterator was created with the same prefix.
> > + */
>
> This statement makes me a little confused. I think there are something
> difference between `seek` and `begin`? For prefix ref iterator, we will
> pass "trim" when calling `begin`, but for seeking, we don't care about
> "trim". Although the prefix maybe the same, but the internal state may
> be different.
Here, as well.
Patrick
