On Mon 07 Apr 08:07, Mark Millard wrote: > On Apr 6, 2025, at 21:11, Gleb Popov <6year...@gmail.com> wrote: > > > On Mon, Apr 7, 2025 at 2:44 AM Mark Millard <mark...@yahoo.com> wrote: > >> > >> So: 2 min 31 sec or so difference for overall somewhat over an > >> hour, i.e., 151 sec or so. That is under 1 sec per package > >> built. > > > > If the slowdown comes from handling shlib provides/requires, then this > > obviously depends on the amount of dependencies of a given package. It > > might be as fast as before for a package with just handful of required > > shlibs, but get exponentially worse for giant ports with a lot of > > deps. > > Looks like a good example of a large factor in the overall time taken > (a factor of around 8 here) for a specific package is beefy17's > recently finished: > > build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Mon Apr 7 > 13:58:19 UTC 2025 > build time: 00:45:07 > > from log: > > https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pad39cc941617_s7a490725045/logs/gnome-metronome-1.3.0_16.log > > I saw this showing lib-depends as the stage with a large time figure > but it had finished when I later went to looks at the log file. > > Compare that to, say, the 2025-Mar-10 : > > https://pkg-status.freebsd.org/beefy17/data/main-i386-default/p9229caa5b2ac_s780a4667bbd/logs/gnome-metronome-1.3.0_16.log > > reporting just: > > build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Mon Mar 10 > 17:46:22 UTC 2025 > build time: 00:05:36 > > There is also (beefy18 instead): > > https://pkg-status.freebsd.org/beefy18/data/main-amd64-default/pad39cc941617_s7a490725045/logs/gnome-metronome-1.3.0_16.log > > with: > > build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Mon Apr 7 > 11:49:09 UTC 2025 > build time: 00:36:13 > > https://pkg-status.freebsd.org/beefy18/data/main-amd64-default/p9229caa5b2ac_s780a4667bbd/logs/gnome-metronome-1.3.0_16.log > > shows: > > build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Tue Mar 11 > 12:36:53 UTC 2025 > build time: 00:04:10 > > That is a little over a factor of 8.6 . > > For reference: > > beefy17: Queued 36539 Built 29757 Remaining 4657 Elapsed 222:10:58 vs. > 74:19:29 > beefy18: Queued 36539 Built 31255 Remaining 4685 Elapsed 222:11:05 vs. > 96:28:10 > > ("vs. ???" shows maximum-Elapsed for a completed build not involving pkg > 2.1.0) > > beefy17 looks to have an overall Elapsed-factor of slightly under 3.0 so far. > beefy18 looks to have an overall Elapsed-factor of slightly over 2.3 so far. > > Looks like these 2 will be the first ones to complete a from-scratch build > based on use of pkg 2.1.0 .
Listing like this is clearly not any useful, the problem we have is the performance changes depending on what is happening in parallel on the machines. which makes the performance issues invisible on local poudriere if you want to test it on port A or port B, if we want to reduce the performance penalty we need to be able to make a reproducible case which can then be profiled, to know where to optimize if needed. I have tried to reproduce each individual case which happen in the ports tree and I am not able to reproduce them, so impossible to know where to look at exactly. I know what is new and what causes the performance penalty, but not which part is causing the super extra penalty on the cluster. Bapt
