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
next 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.