Re: [Qemu-devel] [PATCH for-2.8?] rules.mak: speedup save-vars load-vars

[Daniel P. Berrange]

On Wed, Nov 02, 2016 at 05:24:01PM +0100, Paolo Bonzini wrote:
> Unnesting variables spends a lot of time parsing and executing foreach
> and if functions.  Because actually very few variables have to be
> saved and restored, a good strategy is to remember what has to be done
> in load-vars, and only iterate the right variables in load-vars.
> For save-vars, unroll the foreach loop to provide another small
> improvement.
> 
> This speeds up a "noop" build from around 15.5 seconds on my laptop
> to 11.7 (25% roughly).
> 
> Signed-off-by: Paolo Bonzini <address@hidden>
> ---
>       I'm wondering if this would be acceptable for 2.8.
>       I also have sent patches to GNU make that save another
>       20%, down to 9.8 seconds.
> 
>  rules.mak | 22 ++++++++++------------
>  1 file changed, 10 insertions(+), 12 deletions(-)

I've no objection to your patch right now, but in general I wonder
whether the complexity of unnest-vars is worth it.

What is the intended benefit of using the unnest-vars approach, as
opposed to explicitly including the sub-dir Makefiles and thus directly
adding to the main variables without the recursive expansion step ?

eg today we have:

Makefile.objs:

  util-obj-y = util/

  dummy := $(call unnest-vars,, util-obj-y)

util/Makefile.objs:

  util-obj-y = osdep.o cutils.o unicode.o


Could we instead just do:


Makefile.objs:

  util-obj-y =

  include util/Makefile.objs


util/Makefile.objs:

  util-obj-y += util/osdep.o util/cutils.o util/unicode.o


Yes, you now get the "burden" of adding a directory prefix onto the file
paths, but I don't think that's a big deal, as it is only a one-time
cost when you create a new file, or very rarely move files between dirs.

Without the unnest-vars black magic I think it'd be simpler for mere
mortals to understand what is happening in the makefiles, lowering
the barrier to entry for new contributors to QEMU (and even existing
QEMU contributors who've not had the misfortune of debugging our
recursive make system yet)

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|