Re: Looking for help improving performance (advice or potential contract position)

[Paul Smith]

On Wed, 2014-10-01 at 13:44 -0400, Phil Grabsky wrote:
> Our management doesn't want us taking time to learn the internals of
> make and see if we can improve it ourselves, but they are willing to
> throw money at the problem, either by offering some sort of
> donation/bounty for performance improvements or directly hiring an
> expert on a contract basis; any improvements achieved would of course
> be submitted back to the community as patches.
> 
> Is there an established place to post this sort of offer?
> fossfactory.org seems like what I'm looking for, but it doesn't look
> like it's terribly active.

Hi Phil; posting here or on "address@hidden" is a good start; I don't
know of a specific place otherwise to post except this one:

https://www.fsf.org/resources/jobs

although I don't think it's free.

Of course, we're always interested in performance enhancements
ourselves.  If you or your co-workers can provide some assistance on
testing and investigating issues we may be able to work together.  The
first thing to publish is the version of GNU make you're using and the
platform(s) you're targeting for builds.  The second thing would be to
do some basic performance analysis to see what's going on.  The downside
to this is (a) you will need to put up some developer resources, and (b)
we can't commit to deadlines or even a given level of responsiveness
although we do our best.

I will say a couple of things to check for, offhand: first, be sure
you're using the latest version of GNU make (there will be a new release
"momentarily").  There are performance improvements in 4.0+ for example.

Second, either disable all the built-in rules (with the -r flag) or, if
you can't do that, be sure to disable all the built-in match-anything
rules such as the SCCS and RCS built-in rules.

Be sure, if you have auto-generated dependencies, that you're using the
"new method" and not the one documented in the GNU make manual which
requires re-invoking make.

If that doesn't help much, also consider changing as many pattern rules
as is feasible into static pattern rules.  This will avoid recursive
lookups, although there are some downsides to it as well.

Use "make -pf/dev/null" to see the built-in rules.  Use "make -d" and
look at the work make is doing for targets and see if you can reduce it.

It's not been my experience that recursive variables are typically a
performance problem, except if the value is an invocation of
$(shell ...) or similar, so I wouldn't worry much about that.