Taylor Blau [off-list ref] writes:
This patch avoids an unnecessary tag dereference in
'merge_commit_graph()', which can improve the running time of a
commit-graph write by around ~7.4% on average.
That I suspect depends heavily on what portion of your total
committishes consist of tags, no (in an absurdly extreme case, if
there is no tag in the repository, there won't be any improvement)?
What tag-vs-commit ratio is the above "average" number based on?
Thanks.
On Fri, Mar 20, 2020 at 09:56:16PM -0700, Junio C Hamano wrote:
Taylor Blau [off-list ref] writes:
quoted
This patch avoids an unnecessary tag dereference in
'merge_commit_graph()', which can improve the running time of a
commit-graph write by around ~7.4% on average.
That I suspect depends heavily on what portion of your total
committishes consist of tags, no (in an absurdly extreme case, if
there is no tag in the repository, there won't be any improvement)?
What tag-vs-commit ratio is the above "average" number based on?
I think the point is that in this code path we've already identified the
candidates as commits (because they were in an existing commit-graph
file), so treating the items as a committishes in the first place is
unnecessary. If an object isn't itself a commit, we should be dropping
it from the proposed output (possibly we ought to give a warning in such
a case, too, as it indicates the previous writer did something wrong).
-Peff
On Sat, Mar 21, 2020 at 01:04:55AM -0400, Jeff King wrote:
On Fri, Mar 20, 2020 at 09:56:16PM -0700, Junio C Hamano wrote:
quoted
Taylor Blau [off-list ref] writes:
quoted
This patch avoids an unnecessary tag dereference in
'merge_commit_graph()', which can improve the running time of a
commit-graph write by around ~7.4% on average.
That I suspect depends heavily on what portion of your total
committishes consist of tags, no (in an absurdly extreme case, if
there is no tag in the repository, there won't be any improvement)?
What tag-vs-commit ratio is the above "average" number based on?
I think the point is that in this code path we've already identified the
candidates as commits (because they were in an existing commit-graph
file), so treating the items as a committishes in the first place is
unnecessary. If an object isn't itself a commit, we should be dropping
it from the proposed output (possibly we ought to give a warning in such
a case, too, as it indicates the previous writer did something wrong).
Yes, exactly. Thank you.
-Peff
Thanks,
Taylor