From: Jeff King <peff@peff•net>
To: "erik elfström" <erik.elfstrom@gmail•com>
Cc: Thomas Gummerer <t.gummerer@gmail•com>, Git List <git@vger•kernel.org>
Subject: Re: [PATCH/RFC v3 0/4] Improving performance of git clean
Date: Wed, 22 Apr 2015 15:46:01 -0400 [thread overview]
Message-ID: <20150422194601.GB27656@peff.net> (raw)
In-Reply-To: <CAMpP7NbruKC97L1ROXV0Up9Fks8FJmgB_nxTTWpSHp-8VVE+Xw@mail.gmail.com>
On Wed, Apr 22, 2015 at 09:30:20PM +0200, erik elfström wrote:
> On Tue, Apr 21, 2015 at 11:24 PM, Jeff King <peff@peff•net> wrote:
> >
> > If I understand correctly, the reason that you need per-run setup is
> > that your "git clean" command actually cleans things, and you need to
> > restore the original state for each time-trial. Can you instead use "git
> > clean -n" to do a dry-run? I think what you are timing is really the
> > "figure out what to clean" step, and not the cleaning itself.
>
> Yes, that is the problem. A dry run will spot this particular performance
> issue but maybe we lose some value as a general performance test if
> we only do "half" the clean? Admittedly we clearly lose some value in
> the current state as well due to the copying taking more time than the
> cleaning. I could go either way here.
I guess it is a matter of opinion. I think testing only the "find out
what to clean" half separately is actually beneficial, because it helps
us isolate any slowdown. If we want to add a test for the other half, we
can, but I do not actually think it is currently that interesting (it is
just calling unlink() in a loop).
So even leaving the practical matters aside, I do not think it is a bad
thing to split it up. When you add in the fact that it is practically
much easier to test the first half, it seems to me that testing just
that is a good first step.
-Peff
next prev parent reply other threads:[~2015-04-22 19:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-18 20:41 [PATCH/RFC v3 0/4] Improving performance of git clean Erik Elfström
2015-04-18 20:41 ` [PATCH/RFC v3 1/4] setup: add gentle version of read_gitfile Erik Elfström
2015-04-18 20:41 ` [PATCH/RFC v3 2/4] t7300: add tests to document behavior of clean and nested git Erik Elfström
2015-04-18 20:41 ` [PATCH/RFC v3 3/4] p7300: add performance tests for clean Erik Elfström
2015-04-18 20:41 ` [PATCH/RFC v3 4/4] clean: improve performance when removing lots of directories Erik Elfström
2015-04-19 1:14 ` [PATCH/RFC v3 0/4] Improving performance of git clean Junio C Hamano
2015-04-21 18:17 ` erik elfström
2015-04-20 22:14 ` Thomas Gummerer
2015-04-21 18:21 ` erik elfström
2015-04-21 19:02 ` Junio C Hamano
2015-04-21 21:24 ` Jeff King
2015-04-22 19:30 ` erik elfström
2015-04-22 19:46 ` Jeff King [this message]
2015-04-22 19:53 ` erik elfström
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=20150422194601.GB27656@peff.net \
--to=peff@peff$(echo .)net \
--cc=erik.elfstrom@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=t.gummerer@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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