From: Robert Yang <liezhi.yang@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [RFC] Performance Issue: Build time increases
Date: Tue, 16 Aug 2011 16:37:19 +0800 [thread overview]
Message-ID: <4E4A2C3F.4040309@windriver.com> (raw)
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F2FA7A17F22@shsmsx502.ccr.corp.intel.com>
On 08/12/2011 08:19 PM, Lu, Lianhao wrote:
> Robert Yang wrote on 2011-08-12:
>>
>> Hi folks,
>>
>> The build time of core-image-sato increases about 5 ~ 10 minutes than
>> the following commit:
>>
>> commit 5af197b55a4b779f1ec93186f0723026949ba2b5
>> Author: Liping Ke<liping.ke@intel.com>
>> Date: Fri Jun 3 08:22:40 2011 +0800
>>
>> cache: Implement multiple extra cache fields request support
>
> I think this patch only stores extra information in an extra cache. It only affects the parsing time, and I don't think there will be 5 min difference. How about comparing the "bitbake -e" time with and without the patch(by deleting all the cache files before running bitbake).
>
I'm sorry that I didn't describe it clearly, what I meant was that: This patch
worked correctly, it didn't increase the build time, but other patches after
this one made the build time increased, we just use this commit as a reference
point.
// Robert
> Best Regards,
> -Lianhao
>
>> On my host,
>> 1) the build time of 5af197b55a4b779f1ec93186f0723026949ba2b5 is:
>>
>> real 208m26.133s
>> user 241m29.280s
>> sys 47m0.630s
>>
>> 2) and: 068839698fe192d8846c0ed4db65861448e8e524 is:
>>
>> real 217m39.687s
>> user 255m34.150s
>> sys 48m21.510s
>>
>>
>> I use the bisect build method to find out which patch causes the time
>> increases, but the build time is not stable on my host(Ubuntu 11.04
>> 64bit), e.g., the build time of 1) is 208m at the first build, then
>> "git co other_commit" and build it, after about 10 builds, then go
>> back to build 5af197b55a4b779f1ec, the build time will increases about
>> 8 minutes, I have stopped the X and cron, at. This may have relationship with the linux distribution and disk.
>>
>> So I have to restart the build, reboot the machine by two days, and go
>> on the build. It would be better if anyone has other good method.
>>
>> I think that for the next release(e.g., yocto 1.2), we can find a
>> clean and stable machine(for the distribution, maybe RHEL is more
>> stable than Ubuntu) to check the build time weekly, so that we can notice the performance issue early.
>>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
next prev parent reply other threads:[~2011-08-16 8:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-12 11:06 [RFC] Performance Issue: Build time increases Robert Yang
2011-08-12 12:19 ` Lu, Lianhao
2011-08-16 8:37 ` Robert Yang [this message]
2011-08-15 14:31 ` Richard Purdie
2011-08-16 8:40 ` Robert Yang
2011-08-16 8:56 ` Paul Eggleton
2011-08-16 10:37 ` Robert Yang
2011-08-16 10:59 ` Paul Eggleton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E4A2C3F.4040309@windriver.com \
--to=liezhi.yang@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.