All of lore.kernel.org
 help / color / mirror / Atom feed
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
>



  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.