All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>,
	"Wessel, Jason" <jason.wessel@windriver.com>
Subject: setscene and perl -- pathological case
Date: Thu, 10 May 2012 17:20:31 -0500	[thread overview]
Message-ID: <4FAC3F2F.9000006@windriver.com> (raw)

We've discovered that perl seems to be a pretty bad pathological case for setscene.

Easy way to see what I mean:

bitbake perl
bitbake -c clean perl
time bitbake perl

The system isn't doing anything but running the setscene elements to bring perl 
from the sstate-cache into the sysroot and related directories.. but it takes a 
very long time to do this:

real    3m7.430s
user    0m36.316s
sys     2m46.742s

That is on my 8 core w/ 12 GB of ram system..  (standard SATA disks)

Digging into this, I found that the majority of the time is spent in 
meta/classes/sstate.bbclass: sstate_installpkg

If you look for the three os.system("sed ...  calls, almost all of the 3 minutes 
is there.  Perl has so many text files with embedded paths that a significant 
amount of time is spent preparing these files and fixing paths.

I did a test and changed the three sed cases into a single sed operation:

-            os.system("sed -i -e s:FIXMESTAGINGDIRTARGET:%s:g %s" % 
(staging_target, sstateinst + file))
-            os.system("sed -i -e s:FIXMESTAGINGDIRHOST:%s:g %s" % 
(staging_host, sstateinst + file))
-            os.system("sed -i -e s:FIXMESTAGINGDIR:%s:g %s" % (staging, 
sstateinst + file))
+            os.system("sed -i -e s:FIXMESTAGINGDIRTARGET:%s:g -e 
s:FIXMESTAGINGDIRHOST:%s:g -e s:FIXMESTAGINGDIR:%s:g %s " % (staging_target, 
staging_host, staging, sstateinst + file))

The result:

real    1m20.979s
user    0m19.400s
sys     1m4.115s

This is a very significant performance improvement.  I'm not sure if it's 
possible to speed this up even more, but it would be nice if we could get things 
under a minute.

Does anyone see a way we could do this quicker or in a better way to boost 
performance?  (One possibility is figure out how to thread the file processing 
and use available processors...)

--Mark



             reply	other threads:[~2012-05-10 22:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-10 22:20 Mark Hatle [this message]
2012-05-10 23:12 ` setscene and perl -- pathological case Khem Raj
2012-05-11  5:46 ` Martin Jansa

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=4FAC3F2F.9000006@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=jason.wessel@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.