Hi Duy, On Tue, 23 Oct 2018, Duy Nguyen wrote:
> On Tue, Oct 23, 2018 at 1:01 AM Ben Peart <ben.pe...@microsoft.com> wrote: > > > > > -----Original Message----- > > > From: Johannes Schindelin <johannes.schinde...@gmx.de> > > > Sent: Monday, October 22, 2018 4:45 PM > > > To: Ben Peart <peart...@gmail.com> > > > Cc: git@vger.kernel.org; gits...@pobox.com; Ben Peart > > > <ben.pe...@microsoft.com>; p...@peff.net; sunsh...@sunshineco.com > > > Subject: Re: [PATCH v3 1/3] reset: don't compute unstaged changes after > > > reset when --quiet > > > > > > Hi Ben, > > > > > > On Mon, 22 Oct 2018, Ben Peart wrote: > > > > > > > From: Ben Peart <benpe...@microsoft.com> > > > > > > > > When git reset is run with the --quiet flag, don't bother finding any > > > > additional unstaged changes as they won't be output anyway. This speeds > > > up > > > > the git reset command by avoiding having to lstat() every file looking > > > > for > > > > changes that aren't going to be reported anyway. > > > > > > > > The savings can be significant. In a repo with 200K files "git reset" > > > > drops from 7.16 seconds to 0.32 seconds for a savings of 96%. > > > > > > That's very nice! > > > > > > Those numbers, just out of curiosity, are they on Windows? Or on Linux? > > > > > > > It's safe to assume all my numbers are on Windows. :-) > > It does bug me about this. Next time please mention the platform you > tested on in the commit message. Not all platforms behave the same way > especially when it comes to performance. And pretty much all different testing scenarios behave differently, too. And at some stage, we're asking for too many fries. In other words: we always accepted performance improvements when it could be demonstrated that they improved a certain not too uncommon scenario, and I do not think it would make sense to change this stance now. Not unless you can demonstrate a good reason why we should. Ciao, Johannes
