From: Patrick Steinhardt <ps@pks.im>
To: John Cai <johncai86@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 7/7] reftable/reader: add comments to `table_iter_next()`
Date: Mon, 12 Feb 2024 09:24:53 +0100 [thread overview]
Message-ID: <ZcnV1ULJaurT99tJ@tanuki> (raw)
In-Reply-To: <5335108F-4A21-4429-9BDF-3923D96884C0@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]
On Fri, Feb 09, 2024 at 11:01:13AM -0500, John Cai wrote:
>
> Hi Patrick,
>
> On 1 Feb 2024, at 5:25, Patrick Steinhardt wrote:
>
> > While working on the optimizations in the preceding patches I stumbled
> > upon `table_iter_next()` multiple times. It is quite easy to miss the
> > fact that we don't call `table_iter_next_in_block()` twice, but that the
> > second call is in fact `table_iter_next_block()`.
> >
> > Add comments to explain what exactly is going on here to make things
> > more obvious. While at it, touch up the code to conform to our code
> > style better.
> >
> > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> > ---
> > reftable/reader.c | 26 +++++++++++++++++---------
> > 1 file changed, 17 insertions(+), 9 deletions(-)
> >
> > diff --git a/reftable/reader.c b/reftable/reader.c
> > index 64dc366fb1..add7d57f0b 100644
> > --- a/reftable/reader.c
> > +++ b/reftable/reader.c
> > @@ -357,24 +357,32 @@ static int table_iter_next(struct table_iter *ti, struct reftable_record *rec)
> >
> > while (1) {
> > struct table_iter next = TABLE_ITER_INIT;
> > - int err = 0;
> > - if (ti->is_finished) {
> > + int err;
> > +
> > + if (ti->is_finished)
> > return 1;
> > - }
> >
> > + /*
> > + * Check whether the current block still has more records. If
> > + * so, return it. If the iterator returns positive then the
> > + * current block has been exhausted.
> > + */
> > err = table_iter_next_in_block(ti, rec);
> > - if (err <= 0) {
> > + if (err <= 0)
> > return err;
> > - }
> >
> > + /*
> > + * Otherwise, we need to continue to the next block in the
> > + * table and retry. If there are no more blocks then the
> > + * iterator is drained.
> > + */
> > err = table_iter_next_block(&next, ti);
> > - if (err != 0) {
> > - ti->is_finished = 1;
> > - }
> > table_iter_block_done(ti);
> > - if (err != 0) {
> > + if (err) {
>
> what's the reason for moving the if statement that handles err down after
> table_iter_block_done?
Good question. Ultimately, it's a simplification because I just merge
the two blocks which checked for `err != 0` into a single block. There
is no need to mark the iterator as finished before calling
`table_iter_block_done()`.
So becaiuse `table_iter_block_done()` doesn't inspect `is_finished`,
these two implementations are in the end equivalent. Before:
```
if (err)
ti->is_finished = 1;
table_iter_block_done(ti);
if (err)
return err;
```
After:
```
table_iter_block_done(ti);
if (err) {
ti->is_finished = 1;
return err;
}
```
The latter is much easier to reason about I think. It's also more
efficient because there's one branch less.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-02-12 8:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-01 10:24 [PATCH 0/7] reftable: improve ref iteration performance Patrick Steinhardt
2024-02-01 10:24 ` [PATCH 1/7] reftable/record: introduce function to compare records by key Patrick Steinhardt
2024-02-01 15:00 ` Eric Sunshine
2024-02-01 10:25 ` [PATCH 2/7] reftable/merged: allocation-less dropping of shadowed records Patrick Steinhardt
2024-02-01 10:25 ` [PATCH 3/7] reftable/merged: skip comparison for records of the same subiter Patrick Steinhardt
2024-02-01 17:29 ` Eric Sunshine
2024-02-02 5:15 ` Patrick Steinhardt
2024-02-01 10:25 ` [PATCH 4/7] reftable/pq: allocation-less comparison of entry keys Patrick Steinhardt
2024-02-01 10:25 ` [PATCH 5/7] reftable/block: swap buffers instead of copying Patrick Steinhardt
2024-02-01 10:25 ` [PATCH 6/7] reftable/record: don't try to reallocate ref record name Patrick Steinhardt
2024-02-01 10:25 ` [PATCH 7/7] reftable/reader: add comments to `table_iter_next()` Patrick Steinhardt
2024-02-09 16:01 ` John Cai
2024-02-12 8:24 ` Patrick Steinhardt [this message]
2024-02-12 8:32 ` [PATCH v2 0/7] reftable: improve ref iteration performance Patrick Steinhardt
2024-02-12 8:32 ` [PATCH v2 1/7] reftable/record: introduce function to compare records by key Patrick Steinhardt
2024-02-12 8:32 ` [PATCH v2 2/7] reftable/merged: allocation-less dropping of shadowed records Patrick Steinhardt
2024-02-12 8:32 ` [PATCH v2 3/7] reftable/merged: skip comparison for records of the same subiter Patrick Steinhardt
2024-02-12 8:32 ` [PATCH v2 4/7] reftable/pq: allocation-less comparison of entry keys Patrick Steinhardt
2024-02-12 8:32 ` [PATCH v2 5/7] reftable/block: swap buffers instead of copying Patrick Steinhardt
2024-02-12 8:32 ` [PATCH v2 6/7] reftable/record: don't try to reallocate ref record name Patrick Steinhardt
2024-02-12 8:32 ` [PATCH v2 7/7] reftable/reader: add comments to `table_iter_next()` Patrick Steinhardt
2024-02-12 17:19 ` Junio C Hamano
2024-02-13 6:57 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZcnV1ULJaurT99tJ@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=johncai86@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.