Thread (25 messages) 25 messages, 3 authors, 2021-09-20

Re: [PATCH 2/2] ref-filter: implement "quick" formats

From: ZheNing Hu <hidden>
Date: 2021-09-06 13:35:09

Jeff King [off-list ref] 于2021年9月5日周日 下午9:07写道:
On Sun, Sep 05, 2021 at 04:20:07PM +0800, ZheNing Hu wrote:
quoted
quoted
+       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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help