From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Mon, 17 Jan 2011 17:05:27 +0200." From: Bakul Shah Date: Mon, 17 Jan 2011 08:50:24 -0800 Message-Id: <20110117165024.CC7C75B04@mail.bitblocks.com> Subject: Re: [9fans] `mk` (from Plan9 ports) efficiency related issue Topicbox-Message-UUID: 9d398b78-ead6-11e9-9d60-3106f5b1d025 On Mon, 17 Jan 2011 17:05:27 +0200 Ciprian Dorin Craciun wrote: > On Mon, Jan 17, 2011 at 16:59, erik quanstrom 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.