Hi Duy, On Tue, 23 Oct 2018, Duy Nguyen wrote: > On Tue, Oct 23, 2018 at 1:01 AM Ben Peart <Ben.Peart@xxxxxxxxxxxxx> wrote: > > > > > -----Original Message----- > > > From: Johannes Schindelin <Johannes.Schindelin@xxxxxx> > > > Sent: Monday, October 22, 2018 4:45 PM > > > To: Ben Peart <peartben@xxxxxxxxx> > > > Cc: git@xxxxxxxxxxxxxxx; gitster@xxxxxxxxx; Ben Peart > > > <Ben.Peart@xxxxxxxxxxxxx>; peff@xxxxxxxx; sunshine@xxxxxxxxxxxxxx > > > 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 <benpeart@xxxxxxxxxxxxx> > > > > > > > > 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
