From: Ciprian Dorin Craciun <ciprian.craciun@gmail.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 21:33:31 +0200 [thread overview]
Message-ID: <AANLkTi=K8Kr-wG6NNho8PB2mpp4jCjz-kq==jaYnsujB@mail.gmail.com> (raw)
In-Reply-To: <20110117183601.567225B04@mail.bitblocks.com>
On Mon, Jan 17, 2011 at 20:36, Bakul Shah <bakul+plan9@bitblocks.com> wrote:
> On Mon, 17 Jan 2011 11:56:22 EST erik quanstrom <quanstro@labs.coraid.com> wrote:
>> > 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 :-)
>
>> i don't see how comparing with *make would get one closer
>> to solving the mystery.
>
> The comparison would reveal if other makes do better. I
> suspect they do and that would solve Ciprian's problem.
Ok. So I've transformed (with a `sed` script as suggested) the
script from `mk` to GNU `make. The results is as follows:
* building the entire thing with no parallelism took as in my
experiment -- when I've just obtained the raw commands and runned them
with plain sh -- about 1 minute and 27 seconds seconds;
* after the build issuing `make` a second time take under one
second (0.2 seconds);
I'll try now to profile the `mk` tool as suggested.
Ciprian.
P.S.: I'm not suggesting that GNU `make` is a better tool, just
that for this particular task it behaves better. (Actually I find it
overly complex and almost incomprehensible in its full
implications...)
next prev parent reply other threads:[~2011-01-17 19:33 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
2011-01-17 16:56 ` erik quanstrom
2011-01-17 18:36 ` Bakul Shah
2011-01-17 19:33 ` Ciprian Dorin Craciun [this message]
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='AANLkTi=K8Kr-wG6NNho8PB2mpp4jCjz-kq==jaYnsujB@mail.gmail.com' \
--to=ciprian.craciun@gmail.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).