All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Chris Larson <clarson@kergoth.com>
Cc: Scholz <enrico.scholz@sigma-chemnitz.de>,
	Enrico,
	openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: package: Add cachedpath optimisation
Date: Mon, 18 Mar 2013 16:53:35 +0000	[thread overview]
Message-ID: <1363625615.16482.61.camel@ted> (raw)
In-Reply-To: <CABcZAN=qcf7gxWoAyuArPVCSieiPejOazZX9BOPx03rNWEOCOg@mail.gmail.com>

On Thu, 2013-03-14 at 20:02 -0700, Chris Larson wrote:
> 
> On Thu, Mar 14, 2013 at 6:57 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>         Currently, various standard library operations like os.walk(),
>         os.path.isdir() and os.path.islink() each call stat or lstat
>         which
>         involves a syscall into the kernel. There is no caching since
>         they could
>         conceivably have changed on disk. The result is that for
>         something like
>         the do_package task of the kernel we're spending over two
>         minutes making
>         868,000 individual stat calls for 23,000 files. This is
>         suboptimal.
>         
>         This patch adds lib/oe/cachedpath.py which are a set of
>         replacement
>         functions for these operations which use cached stat data
>         rather than
>         hitting the kernel each time. It gives a nice performance
>         improvement
>         halving the build time of the kernel do_package.
>         
>         Signed-off-by: Richard Purdie
>         <richard.purdie@linuxfoundation.org>
> 
> Have you considered having the initcache() return a cache object,
> either with the rest as methods on it, or pass that in? I think it'd
> be substantially cleaner than messing with globals, particularly given
> with globals we tend to have issues with cache lifetime and
> invalidation — if the cache was returned, it would go away when the
> object gets collected.

Agreed. Due to the way package.bbclass is structured, we currently need
a global there but that is no reason we shouldn't have a sensible
class/object structure for the new code. I've sent out a v2 which
hopefully does better in that regard.

Cheers,

Richard
> 





      reply	other threads:[~2013-03-18 17:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-15  1:57 package: Add cachedpath optimisation Richard Purdie
2013-03-15  3:02 ` Chris Larson
2013-03-18 16:53   ` Richard Purdie [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=1363625615.16482.61.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=clarson@kergoth.com \
    --cc=enrico.scholz@sigma-chemnitz.de \
    --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.