On Fri, Jan 5, 2024 at 6:52 PM Peter Humphrey <pe...@prh.myzen.co.uk> wrote:
> Hello list, > > I've just had some strange output from genlop on my 16-thread i5 box, thus: > > # genlop -t libreoffice | /bin/grep minute > merge time: 37 minutes and 38 seconds. > merge time: 52 minutes and 59 seconds. > merge time: 46 minutes and 17 seconds. > > # genlop -c > > Currently merging 11 out of 11 > > * app-office/libreoffice-7.5.9.2 > > current merge time: 4 minutes and 3 seconds. > ETA: 1 hour, 4 minutes and 24 seconds. > > ### Then, once the update finished: > > # genlop -t libreoffice | /bin/grep minute > merge time: 37 minutes and 38 seconds. > merge time: 52 minutes and 59 seconds. > merge time: 46 minutes and 17 seconds. > merge time: 38 minutes and 40 seconds. > > I know genlop is, shall we say, not perfect, but how can it be so grossly > wrong as that? > > I have this in make.conf, and it hasn't changed since I built the machine: > > grep '\-j' /etc/portage/make.conf > EMERGE_DEFAULT_OPTS="--jobs --load-average=12 > MAKEOPTS="-j12 -l12" > > -- > Regards, > Peter. I’ve often found that it gives one estimate when multiple packages are being built, then a much longer estimate for still-in-progress builds once some of the builds have finished. That result defies common sense. Less remaining work has to take less, not more (much more), time. This observation tells me that the algorithm is very fundamentally broken. The only way to answer how it can be so grossly wrong is to examine its algorithm. That’s been on my to-do list for ages, but the thought of debugging it has so far not risen to worth-the-effort status. I use nearly the same build options as you, so perhaps we’re triggering the same problem. But my less-work-implies-longer-time observations suggests to me that the problem is more fundamental than details of jobs/threads/etc. John Blinka >
