From: Peter Seebach <peter.seebach@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [PATCH 0/2] Variable tracking: Cleaned up and rebased.
Date: Wed, 16 Jan 2013 12:01:04 -0600 [thread overview]
Message-ID: <20130116120104.1d40cced@e6410-2> (raw)
In-Reply-To: <1358358898.24249.8.camel@ted>
On Wed, 16 Jan 2013 17:54:58 +0000
Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> I *really* want to take these, however I did want to check
> performance:
Oh, good thought.
> $ time bitbake core-image-sato -e
> real 0m8.034s
> $ time bitbake -p
> real 0m12.220s
> user 3m3.887s
> After:
> $ time bitbake core-image-sato -e
> real 0m50.267s
> $ time bitbake -p
> real 0m14.607s
> user 3m55.179s
Hmm. That doesn't totally surprise me.
> The 50s seems a touch excessive and it looks like a 20% parsing hit
> even when unused :(. Note the overall parsing times on this machine
> are fast as its running 24 in parallel. I'm going to try and figure
> out what is going on tomorrow as I've fixed a lot of this kind of
> thing in the past but wanted to mention it...
The 50s seems... not entirely surprsing. I don't know that much about
how Python does stuff, but in practice we end up with a LOT of deep
copies of structures floating around because there are a ton of data
copies; without these, finalize information gets duplicated and things
go pretty wrong.
My intuition is that the stack backtrace thing is probably expensive,
and might be noticably reduced by manually passing in the
likely-missing values in cases where we know what they are, so it's
less likely that any backtracing has to happen.
-s
--
Listen, get this. Nobody with a good compiler needs to be justified.
next prev parent reply other threads:[~2013-01-16 18:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-12 1:40 [PATCH 0/2] Variable tracking: Cleaned up and rebased Peter Seebach
2013-01-12 1:40 ` [PATCH 1/2] data_smart.py and friends: Track file inclusions for bitbake -e Peter Seebach
2013-01-12 1:40 ` [PATCH 2/2] data_smart.py and friends: Track variable history Peter Seebach
2013-01-16 17:54 ` [PATCH 0/2] Variable tracking: Cleaned up and rebased Richard Purdie
2013-01-16 17:59 ` Richard Purdie
2013-01-16 18:01 ` Peter Seebach [this message]
2013-01-17 11:04 ` Richard Purdie
2013-01-17 11:29 ` Richard Purdie
2013-01-18 11:58 ` Richard Purdie
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=20130116120104.1d40cced@e6410-2 \
--to=peter.seebach@windriver.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.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.