Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Trent Piepho <tpiepho@impinj.com>
To: buildroot@busybox.net
Subject: [Buildroot] 2019.02 performance
Date: Tue, 12 Mar 2019 20:30:50 +0000	[thread overview]
Message-ID: <1552422649.7410.30.camel@impinj.com> (raw)
In-Reply-To: <20190312090518.692f21a9@windsurf>

On Tue, 2019-03-12 at 09:05 +0100, Thomas Petazzoni wrote:
> 
> A hot ccache will drastically decrease the time of the "build" step of
> each package, and make the "configure" and "install" steps look
> comparatively very long. A build without ccache support or with a cold
> cache will show a much larger "build" time I believe.

Yes, it will be larger.  I don't have a benchmark handy with that info.
 Perhaps I'll do one overnight.  But what I see here, is that nearly
every build we do, both manually and as part of CI, has a very high
ccache hit rate.  I was keeping track of the stats from CI for a while
on that.  

> > 
> > pkg_size is much more reasonable now.  In total, these are about 10.2%
> > of the total build time.
> 
> 10% just for the instrumentation is still a lot. Our of 22 minutes of
> your build time, it's still ~2 minutes. The clear dominating factor

This is just the build image time (from scratch + ccache).  There is
also a documentation build, and steps like legal info, package build
time graphs, and dependency graphs are quite long.  The dependency
graphs are clearly the biggest low hanging fruit once this step is
considered.

Though check host rpath could be sped up!  One thing that might skew
these results is our host packages to target packages ratio might be
higher than typical.  If I took out the host based python software and
host based image crypto signing stuff there'd be a lot fewer host ELF
files.

      parent reply	other threads:[~2019-03-12 20:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11 21:59 [Buildroot] 2019.02 performance Trent Piepho
2019-03-12  8:05 ` Thomas Petazzoni
2019-03-12  9:57   ` Arnout Vandecappelle
2019-03-12 20:30   ` Trent Piepho [this message]

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=1552422649.7410.30.camel@impinj.com \
    --to=tpiepho@impinj.com \
    --cc=buildroot@busybox.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox