Re: bmake inefficiencies

["Simon J. Gerraty" <sjg%juniper.net@localhost>]

> > I had a look with truss at what bmake is doing and I think a lot of
> > the syscalls can be easily avoided. Examples come from FreeBSD with
> > bmake-20210110 and I don't know to what extent they are representative
> > for other systems.
> >
> > 1. spurious waitpid
> >
> > when doing buildkernel I counted the following:
> > 7010 cases of error code 0 (== nothing to do)
> > 371 cases of ECHILD
> > 1526 cases of reaping
> 
> I'm not familiar enough with waitpid, so I will not touch this topic.
> Simon?

There's a gratuitous call to Job_CatchChildren in Job_CatchOutput.

It should probbaly suffice to call Job_CatchChildren after a SIGCHLD.
It is a common misstake to assume that SIGCHLD will be receieved for each
child - which is why looping in Job_CatchChildren is important.
This means there will always be a wasted waitpid per call to
Job_CatchChildren. 

> > 2. FD_CLOEXEC
> >
> > for example mkstemp is used and FD_CLOEXEC performed on the result.
> > Instead mkostemp can be used and mkTempFile can accept O_CLOEXEC as an
> > argument to save explicit fcntl.
> 
> On current NetBSD and FreeBSD, this may be fine, for other platforms
> there would need to be autoconf support.  Simon?

Yes bmake runs on many very old systems, so 
there's a balance to be struck between ifdef hell and
making best use of modern features.

Using autoconf makes this more manageable.

> > 3. avoidable temp files
> >
> > JobOpenTmpFile opens a file and later checks if anything was written
> > to it. Not an actual patch, but a hack to demonstrate the fix can be
> > found at the end. Looks like checking can be done upfront in O(1) time
> > (not done in the patch below).
> >
> > With this in place I get the following result for buildworld:
> > 87930 JobOpenTmpFile: created!
> > 70564 JobOpenTmpFile: skipped!
> > i.e. about 44% of all temp files can be avoided at least in this workload.

Avoiding file I/O would be useful.

--sjg