When Go 1.26rc2 was being tested in the OpenBSD ports tree, it was noticed that Grafana was building slower than it had previously (with Go 1.25.6). Since the build machinery is building a large volume of packages, limitations are in place to prevent builds from trying to take over the entire machine - part of this appears to be (understandably) aggravated by GOMAXPROCS=1, however even increasing this to 2 or 4, there is still a seemingly ~5% slowdown in build time:
With -p=1 and GOMAXPROCS=1:
1.25.6:
15m31.78s real 11m18.22s user 2m45.24s system
1.26rc2
18m18.46s real 13m46.76s user 2m57.95s system
With -p=2 and GOMAXPROCS=2:
1.25.6:
10m11.78s real 19m07.66s user 5m05.13s system
1.26rc2:
10m38.15s real 19m31.14s user 5m27.86s system
With -p=2 and GOMAXPROCS=4:
1.25.6:
9m21.32s real 23m38.35s user 7m13.84s system
1.26rc2:
9m56.93s real 24m53.99s user 7m44.58s system
I've not had time to try to trace this further, or verify on other environments (not sure if it is potentially expected). Figured it was worth reporting all the same.
When Go 1.26rc2 was being tested in the OpenBSD ports tree, it was noticed that Grafana was building slower than it had previously (with Go 1.25.6). Since the build machinery is building a large volume of packages, limitations are in place to prevent builds from trying to take over the entire machine - part of this appears to be (understandably) aggravated by
GOMAXPROCS=1, however even increasing this to 2 or 4, there is still a seemingly ~5% slowdown in build time:With -p=1 and GOMAXPROCS=1:
With -p=2 and GOMAXPROCS=2:
With -p=2 and GOMAXPROCS=4:
I've not had time to try to trace this further, or verify on other environments (not sure if it is potentially expected). Figured it was worth reporting all the same.