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
