9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Bakul Shah <bakul+plan9@bitblocks.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] `mk` (from Plan9 ports) efficiency related issue
Date: Mon, 17 Jan 2011 08:50:24 -0800	[thread overview]
Message-ID: <20110117165024.CC7C75B04@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Mon, 17 Jan 2011 17:05:27 +0200." <AANLkTikS14V0CWMc72JQwaV=H-LgmxrMYvGnid+RhmZE@mail.gmail.com>

On Mon, 17 Jan 2011 17:05:27 +0200 Ciprian Dorin Craciun <ciprian.craciun@gmail.com>  wrote:
> On Mon, Jan 17, 2011 at 16:59, erik quanstrom <quanstro@quanstro.net> wrote=
> :
> >> Any ideas what could cause this?
> >
> > have you tried profiling mk?
> >
> > - erik
>
>     In fact I tried to `strace -f -T` it and it seems that in the
> first second or so it `stats` all the files that exist, and then it
> just waits 14 seconds computing something (100% processor), and
> concludes that all is already built. (This is after I've already
> successfully built it once).

strace tells you what system calls were made and when.  To
find out which functions use most time, compile with -pg and
look at the gprof output once done.  That 14 seconds were
probably spent computing dependencies.  You can convert your
test.mk to a Makefile with a trivial sed script. See what
bsdmake or gmake does with it time wise. {bsd,g}make have
been been abused with huge Makefiles for far longer and are
likely to be friendlier to them :-)

But the real issue is that mk has to check all the long
dependency chains your generator creates and it is probably
not tuned for such large mkfiles as typically one factors out
build logic in a set of mkfiles and uses meta rules where
appropriate.



  reply	other threads:[~2011-01-17 16:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-17 14:47 Ciprian Dorin Craciun
2011-01-17 14:59 ` erik quanstrom
2011-01-17 15:05   ` Ciprian Dorin Craciun
2011-01-17 16:50     ` Bakul Shah [this message]
2011-01-17 16:56       ` erik quanstrom
2011-01-17 18:36         ` Bakul Shah
2011-01-17 19:33           ` Ciprian Dorin Craciun
2011-01-17 19:59           ` Ciprian Dorin Craciun
2011-01-17 20:30             ` Bakul Shah
2011-01-17 15:00 ` Robert Raschke
2011-01-17 15:02   ` Robert Raschke
2011-01-17 15:18     ` erik quanstrom
2011-01-17 15:33   ` Ciprian Dorin Craciun
2011-01-17 15:51     ` Federico G. Benavento
2011-01-17 15:53     ` Robert Raschke
2011-01-17 16:02       ` andrey mirtchovski
2011-01-17 16:45         ` Ciprian Dorin Craciun
2011-01-17 17:31       ` Ciprian Dorin Craciun
2011-01-17 17:46         ` Federico G. Benavento
2011-01-17 17:51           ` Federico G. Benavento
2011-01-18  6:09         ` Andy Spencer
2011-01-18 13:26           ` erik quanstrom
2011-01-17 15:21 ` Ciprian Dorin Craciun

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=20110117165024.CC7C75B04@mail.bitblocks.com \
    --to=bakul+plan9@bitblocks.com \
    --cc=9fans@9fans.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;
as well as URLs for NNTP newsgroup(s).