Date: Thu, 2 May 2024 22:18:09 +0200 From: Peter <pmc@citylink.dinoex.sub.org> To: Brooks Davis <brooks@freebsd.org> Cc: ports@freebsd.org Subject: Re: git ports-tree doesn't work, please check! Message-ID: <ZjP1AQXXqY3_QhJY@disp.intra.daemon.contact> In-Reply-To: <ZjPkkhoun-BetjOl@spindle.one-eyed-alien.net> References: <ZjPd3GPWQKHgFB6i@disp.intra.daemon.contact> <ZjPkkhoun-BetjOl@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 02, 2024 at 07:08:02PM +0000, Brooks Davis wrote: ! On Thu, May 02, 2024 at 08:39:24PM +0200, Peter wrote: ! > ! > $ fetch https://cgit.freebsd.org/ports/log/devel/py-python-dateutil ! > fetch: transfer timed out ! > ! > My local replica has the same problem, git goes into a loop at that ! > location. ! ! Hmm, testing locally there's only a single commit to that path (moving ! it from Move devel/py-dateutil) so git has to read the whole commit ! history to discover there is only one commit. Even on a 40-core machine ! with nvme disks that's very slow process (but it does eventually ! complete). There is only that single commit, yes. And git has to read the whole history to find that there are no more. But that is true for any location if you read the log all to the end. # time sh -c "git log -- bin/bash > /dev/null" 10.199u 1.824s 0:16.38 73.3% 3413+446k 4619+0io 6829pf+0w Again, without spinup (these are mechanical) and from the ARC: # time sh -c "git log -- bin/bash > /dev/null" 5.446u 0.456s 0:05.91 99.6% 3409+446k 0+0io 0pf+0w Now a tough one: # time sh -c "git log -- www/firefox > /dev/null" 14.071u 0.707s 0:16.74 88.2% 3382+442k 1270+0io 1586pf+0w But then: # time sh -c "git log -- devel/py-python-dateutil > /dev/null" 82.180u 0.598s 1:23.64 98.9% 3418+447k 935+0io 1630pf+0w And it gets worse on repetition: # time sh -c "git log -- devel/py-python-dateutil > /dev/null" 113.464u 0.331s 1:55.99 98.1% 3411+446k 0+0io 0pf+0w # time sh -c "git log -- devel/py-python-dateutil > /dev/null" 133.253u 0.441s 2:22.12 94.0% 3413+446k 0+0io 0pf+0w This is not the io and pf, it is a compute loop in git - and it is done single-core, so neither vCores nor NVMe help here. ! I suspect cgit is timing out because it's looking for enough logs to fill ! a single page before sending a reply. That is probably timing out after some fixed time, maybe 60 sec. ! This is an advantage of github's ! progressive rendering (and the pile of javascript it requires). For ! example, see: ! ! https://github.com/freebsd/freebsd-ports/commits/main/devel/py-python-dateutil ! ! where you get the first commit and then a spinning thing for a bit ! before "End of commit history for this file" appears. That is different, indeed. I suppose different preprocessing: whatever git needs to compute during these 80 seconds, is already cached there. The javascript (presentation layer) is a different matter - what I am asking is, what is computed within the 80 seconds and how does that happen? Because I have not seen similar before. Maybe it has a simple explanation, maybe it will be optimized away at some point, or maybe it gets worse...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZjP1AQXXqY3_QhJY>