Compared with 2.1.2 (krogoth) the time of building "rootfs" has been increased in around 20% on Ubuntu and 11% on Fedora Charts : https://wiki.yoctoproject.org/charts/perf_milestone_GDC/bitbake-core-image-sato-rootfs.html 2.1.2 commit: cca8dd15c8096626052f6d8d25ff1e9a606104a3 2.1.3 commit: 3565a9697f53ba975a1b7235b802f659418746c3 ============================================================= Ubuntu Test 2.1.2_rc1 2.1.3_rc1 % rootfs 1:59 2:26 22.69 Fedora Test 2.1.2_rc1 2.1.3_rc1 % rootfs 2:01 2:15 11.57
Jose, these are the times obtained during the weekend on the ubuntu perf machine (ypperf02) #2.1.2 (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.62 (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.68 (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.26 # commit in the middle between 2.1.2 and 2.1.3 (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.19 (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.29 (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.53 # 2.1.3 (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:12.06 (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:11.73 (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:11.82 meaning that between *.2 and *.3 there is an increase of around one second which is pretty small compared to what you observed. I will let you decide what to do with this bug. One more thing: after 2.1.3, is the perf machine rebooted? Experimentally, RP has observed that long uptimes may lead longer perf times, so it may be wise to reboot machines once in a time.
(In reply to comment #1) > Jose, > > these are the times obtained during the weekend on the ubuntu perf machine > (ypperf02) > > > #2.1.2 > (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.62 > (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.68 > (HEADdetachedatcca8dd1):cca8dd15c8096626052f6d8d25ff1e9a606104a3,2:10.26 > > # commit in the middle between 2.1.2 and 2.1.3 > (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.19 > (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.29 > (HEADdetachedat4cd7b56):4cd7b5622879e5899dc6c8e0e343eb07a66cf60f,2:11.53 > > # 2.1.3 > (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:12.06 > (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:11.73 > (HEADdetachedat3565a96):3565a9697f53ba975a1b7235b802f659418746c3,2:11.82 > > meaning that between *.2 and *.3 there is an increase of around one second > which is pretty small compared to what you observed. I will let you decide > what to do with this bug. I will close this as not a bug > > One more thing: after 2.1.3, is the perf machine rebooted? Experimentally, > RP has observed that long uptimes may lead longer perf times, so it may be > wise to reboot machines once in a time. Yes that was the cause also observed on most recent releases, There is a plan already set to reboot machines on a regularly, now the numbers are more consistent.