From: David Kastrup <dak@gnu.org>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2] Bump core.deltaBaseCacheLimit to 128MiB
Date: Fri, 21 Mar 2014 09:11:19 +0100 [thread overview]
Message-ID: <87eh1wc6oo.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <20140320234859.GD7774@sigill.intra.peff.net> (Jeff King's message of "Thu, 20 Mar 2014 19:48:59 -0400")
Jeff King <peff@peff.net> writes:
> If you have before-and-after numbers for just this patch on some
> repository, that would be an interesting thing to put in the commit
> message.
It's a hen-and-egg problem regarding the benchmarks. The most
impressive benchmarks arise with the git-blame performance work in
place, and the most impressive benchmarks for the git-blame performance
work are when this or something similar is in place. Of course, when
there are two really deficient things slowing operations down, fixing
only one is going to be much less impressive.
So I decided to tackle the low-hanging fruit here first. But it would
appear that this amounts in far too much work since it means I have to
search for and create some _other_ benchmarking scenario not hampered by
substandard code like the current git-blame is.
I have enough on my plate as it is, so even though it puts the _real_
git-blame work in a worse light, I should rather get that finished first
(nobody will argue to keep the useless threshing of it around). Of
course, the person then creating the two-line change to
deltaBaseCacheLimit will be able to claim much larger performance
improvements in his commit message afterwards than what I can claim
regarding the git-blame work when going first, but that's life.
--
David Kastrup
prev parent reply other threads:[~2014-03-21 8:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 12:38 [PATCH v2] Bump core.deltaBaseCacheLimit to 128MiB David Kastrup
2014-03-19 21:09 ` Junio C Hamano
2014-03-19 21:25 ` David Kastrup
2014-03-19 22:11 ` Junio C Hamano
2014-03-20 1:38 ` Duy Nguyen
2014-03-20 17:02 ` Junio C Hamano
2014-03-20 17:08 ` David Kastrup
2014-03-20 22:35 ` Junio C Hamano
2014-03-21 6:04 ` David Kastrup
2014-03-21 7:59 ` Duy Nguyen
2014-03-21 8:02 ` David Kastrup
2014-03-20 23:48 ` Jeff King
2014-03-21 6:12 ` David Kastrup
2014-03-21 8:11 ` David Kastrup [this message]
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=87eh1wc6oo.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).