From: Pratyush Yadav Date: Sun, 04 Aug 2019 12:53:15 GMT Subject: Re: [PATCH] git-gui: Perform rescan on window focus-in Message-ID: <1489be05-ab18-a3e5-dd38-3d5729ebe67a@yadavpratyush.com> In-Reply-To: On 8/4/19 2:04 AM, Johannes Schindelin wrote: > Hi, > > On Sat, 3 Aug 2019, Pratyush Yadav wrote: > >> On 8/2/19 6:09 PM, Johannes Schindelin wrote: >>> >>> On Fri, 2 Aug 2019, Pratyush Yadav wrote: >>> >>>> On 8/1/19 1:12 AM, Johannes Schindelin wrote: >>>>> >>>>> I would be _extremely_ cautious to base an argument on one >>>>> particular setup, using on particular hardware with one >>>>> particular OS and one particular repository. >>>>> >>>> >>>> Agreed. That's why I asked for benchmarks from other people. >>>> Unfortunately, no one replied. >>> >>> What stops _you_ from performing more tests yourself? There are tons >>> of real-world repositories out there, we even talk about options for >>> large repositories to test with in Git for Windows' Contributing >>> Guidelines: >>> https://github.com/git-for-windows/git/blob/master/CONTRIBUTING.md#performance-tests >> >> I thought the point was to not base all data off a single setup? > > You misunderstood what I was saying: a single setup is bad, and you can > make it moderately better by testing _at least_ with a moderately-sized > repository [*1*] in addition to git.git. > > So yes, it would still not be enough to test with, say, the git.git > _and_ the Chromium repository _only_ on your setup, but if not even you > can be bothered to test with more than one small repository, how can you > possibly expect anybody else to add more testing? All right, I'll see what repos I can test. But my internet is pretty slow and unstable, so my clone of the Chromium repo failed mid-way multiple times. I assume we need to test on a large index, so is it all right if I use t/perf/repos/many-files.sh to artificially generate a large repo? > >> [...] >>> I wonder, however, whether you can think of a better method to >>> figure out when to auto-refresh. Focus seems to be a low-hanging >>> fruit, but as you noticed it is not very accurate. Maybe if you >>> combine it with a timeout? Or maybe you can detect idle time in >>> Tcl/Tk? >> >> Hm, I don't see a better alternative than file system watches. >> Timeouts are a heuristic that can potentially be problematic. > > Let me stress the fact that I suggested a timeout _in addition_ to the > focus event? Oh, my bad. I thought you suggested using timeouts exclusively. But I'm not sure I understand what you mean by "using timeouts in addition to the focus event". My guess is that you mean we should activate a refresh-on-focus-in only after git-gui has been out of focus for a certain amount of time. Is my guess correct? > > Yes, using a timeout on its own is stupidly problematic. That's why I > did not suggest that. > >> If you do a refresh too frequently, you hog up the user's resources >> for little benefit. > > Indeed. You want to find a heuristic that catches most of the cases > where files were changed, while at the same time not even _trying_ to > refresh automatically when probably nothing changed. Like I said before, the best way of doing that that I can see is file system watches. But maybe we can get reasonable performance with a combination of timeouts and focus events. > >> You don't refresh frequently enough, then sometimes the user sees an >> updated view, sometimes a not-updated view. This inconsistency, if not >> fine tuned properly, can prove detrimental to UX. > > Right, exactly. And of course, since you are not changing your own Git > fork only, but the Git that is the one that most users will use, you > will have to consider carefully in which direction to strike the balance > by default. Yep, that's why I'm engaging you in this conversation :). I'm personally pretty happy with this change for my own use, but I'd like everyone enjoy it equally. > > I would contend that you should err on the side of _not_ refreshing, as > that would probably affect more users negatively than the opposite. > > Ciao, > Johannes > > Footnote *1*: I don't expect you to test with the largest repositories, > as you are unlikely to have access to anything approaching the size of > the largest Git repository on the planet: > https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ > Ah yes, I read about it a while back on Reddit. Having a huge monolithic repo sounds backwards to me. Using submodules sounds like a better idea, but who am I to judge. They probably have their reasons that I'm not aware of. -- Regards, Pratyush Yadav