Hi Saul, As you know, the build system patch [1] had introduced the pbr command to generate pkg version. This should be the only effect on the compile time of pbr enabled pkg.
Jitstack had tested command execution time. The result of "with pbr" should be the command execution time. Please correct me if my understanding is wrong. But the result of "without pbr" should be "0". Build system will not execute pbr command if it is not enabled. If your just instrumenting the "pbr execution time", then I guess then without pbr should be 0. based on your comments during the Distro call,
On 2/12/20 6:32 AM, Yang, Bin wrote: the build time with pbr enabled becomes noise in the minutes that it takes to do a build. It's just not clear from below what was being tested, I think this sort of clarifies things. Let's get some feedback from the rest of the Build team (Scott, Don)? Thanks Sau!
Thanks, Bin
[1]: https://review.opendev.org/#/c/691632/
-----Original Message----- From: Saul Wold <sgw@linux.intel.com> Sent: Tuesday, February 4, 2020 23:09 To: wesley.yang@jitstack.com; daniels.cai@jitstack.com; Yang, Bin <bin.yang@intel.com>; shangyakun@jitstack.com Cc: Hu, Yong <yong.hu@intel.com>; starlingx-discuss@lists.starlingx.io Subject: Re: 回复: PBR Status Check
Wesley, Yakun:
I hope you guys are doing OK with the restrictions and stay healthy!
I did a review of the numbers that Yakun provide in a prior email (summary here)
Package Compile timeconsumption with pbr without pbr the first time 0.287s 0.301s the second time 0.322s 0.351s the third time 0.554s 0.235s the fourth time( deb package) 0.299s 0.292s
Can you please provide more details about what your actual test methodology (and/or scripts) was?
I think at some-point it was suggested that 2 packages (python and non-python) should be used. They should then be compiled / cleaned in a loop of about 10-12 times to ensure any caches are cleared. Then an average and deviation be determined.
Thanks Sau!
On 2/4/20 12:27 AM, wesley.yang@jitstack.com wrote:
Hi Saul I'm working at home remotely at home for the Government's restriction, my colleagues are also working remotely or still on vacation. You may see that my colleagues Yakun has just sent the preliminary result to you, and he will do some more test and update later.
Wesley
-----邮件原件----- 发件人: Saul Wold <sgw@linux.intel.com> 发送时间: 2020年2月4日 8:54 收件人: wesley.yang@jitstack.com; daniels.cai@jitstack.com; Yang, Bin <bin.yang@intel.com> 抄送: Hu, Yong <yong.hu@intel.com>; starlingx-discuss@lists.starlingx.io 主题: Re: PBR Status Check
Hi Wesley,
Following up on this, I am not sure what your working status is because of the Virus and various Gov't restrictions. If you are working, can you give us an update on the Performance impact question I listed below.
Thanks Sau!
On 1/22/20 10:14 AM, Saul Wold wrote:
Hi All & Welcome Wesley,
We have a new community member from JitStack starting to look at the PBR work, here is some background for him.
The PBR work was proposed via the StarlingX Feature Specification process, see the Flock Versioning specification [0], this is based on the OpenStack Python Build Reasonableness [1] and Semantic Versioning (SemVer) [2] definition.
One of the issues that we are trying to resolve is the impact of the proposed change from Bin Yang to the time it takes to build a single package with PBR before and after the change. Ideally this would be done multiple times and provide the average along with the deviation. This in an important part of the project in order for us to move forward.
Look forward to working with you.
Sau!
[0] https://docs.starlingx.io/specs/specs/stx-3.0/approved/standardize_fl o ck_versioning.html
[1] https://docs.openstack.org/pbr/latest/ [2] https://docs.openstack.org/pbr/latest/user/semver.html