Re: [PATCH 2/2] ref-filter: implement "quick" formats
- From
ZheNing Hu <adlternative@gmail.com>
- Date
- Sep 6, 2021, 13:34 UTC
- Message-ID
- <CAOLTT8QqLXdvL5Y8OkEzuctGgnDHA1DQu8ZaxQGnfHPBqNVm4g@mail.gmail.com>
- In-Reply-To
- <YTTBCWlsC1cBZMio@coredump.intra.peff.net>
Jeff King <peff@peff.net> 于2021年9月5日周日 下午9:07写道:
Show 27 quoted lines
>
> On Sun, Sep 05, 2021 at 04:20:07PM +0800, ZheNing Hu wrote:
>
> > > + case REF_FORMAT_QUICK_OBJECTNAME_REFNAME:
> > > + printf("%s %s\n", oid_to_hex(oid), refname);
> > > + return 0;
> > > + }
> > > + BUG("unknown ref_format_quick value: %d", format->quick);
> > > +}
> > > +
> >
> > So as a fast path, we actually avoided format_ref_array_item() when we are using
> > %(objectname) and %(refname). But the problem is that it’s not very elegant
> > (using string compare), and it is no optimization for other atoms that
> > require in-depth
> > parsing. I remember the "fast path" used by Ævar last time, and it
> > seems that Junio doesn't
> > like them. [1][2]
>
> Yes, I did say it was "pretty horrible". :)
>
> It was mostly meant as a proof-of-concept to see where the time was
> going, and what was possible. It _could_ be used as a stop-gap while
> improving the general performance, but it's gross enough that it's
> probably not a good idea (it's increased maintenance, but also it
> dis-incentivizes fixing the real problems).
>Agree. Like you said, these performance gaps are caused by the used_atom system.
> -Peff
Thanks. -- ZheNing Hu