public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: "R. Diez" <rdiezmail-newlib@yahoo.de>,
	joel@rtems.org, Newlib <newlib@sourceware.org>,
	Matthew Joyce <matthew.joyce@embedded-brains.de>
Subject: Re: Question about autoreconf to regenerate configuration files
Date: Thu, 17 Feb 2022 00:18:30 -0500	[thread overview]
Message-ID: <Yg3apoTMTMojanx/@vapier> (raw)
In-Reply-To: <YfEcPccYyuXIO+zF@vapier>

[-- Attachment #1: Type: text/plain, Size: 2961 bytes --]

On 26 Jan 2022 05:02, Mike Frysinger wrote:
> On 21 Jan 2022 17:09, Mike Frysinger wrote:
> > On 21 Jan 2022 17:09, R. Diez via Newlib wrote:
> > > > [...]
> > > > The bootstrap time was large enough to
> > > > negatively impact our ability to do automated regression testing.
> > > 
> > > A very long bootstrap time could be an issue.
> > > 
> > > However, compilation time normally outweighs by far the Autotools regeneration step. Is that a problem in Newlib at the moment?
> > 
> > autotools (autoreconf really) doesn't run in parallel, so every subdir
> > with a configure script needs a separate serialized run of all the tools.
> > newlib has many many of these (arguably, too many).
> > 
> > on my quad core 4.2GHz AMD that is otherwise idle ...
> > 
> > $ time (cd newlib && autoreconf)
> > real    5m22.170s
> > user    3m13.709s
> > sys     0m12.332s
> > 
> > $ time (cd libgloss && autoreconf)
> > real    1m41.754s
> > user    0m43.505s
> > sys     0m3.618s
> > <this errored out, not sure why, so it might normally take even longer :p>
> > 
> > # Blackfin builds 8 copies (multilib) of newlib+libgloss by default.
> > $ time (cd build; ../configure --host=bfin-elf; make -j4)
> > real    1m40.950s
> > user    0m58.032s
> > sys     0m30.968s
> 
> updated timings on my system after recent work to delete many configure scripts
> $ time (cd newlib && autoreconf)
> real    1m0.619s
> user    0m45.249s
> sys     0m1.535s
> 
> $ time (cd libgloss && autoreconf -I$PWD -I$PWD/.. -I$PWD/../config)
> real    0m32.662s
> user    0m15.858s
> sys     0m1.205s
> 
> $ time (cd build; ../configure --host=bfin-elf; make -j4)
> real    1m2.337s
> user    0m44.987s
> sys     0m26.708s
> 
> so it's def better, but autotool generation still takes longer than actually
> compiling newlib+libgloss 8 times :).

things are looking up.  with all my pending changes, we have 1 configure script
in newlib and no recursive makes.

$ time (cd newlib && autoreconf)
real    0m8.740s
user    0m7.524s
sys     0m0.193s

i'm not sure if i'll "finish" libgloss.  there's still a lot of subdirs not
even using automake, so while i can kill most configure scripts, i prob won't
do them all, and i prob won't convert more to automake or non-recursive make.
the libgloss arches have a lot harrier logic in them that i don't care to try
to unpack, especially since i converted the dirs i most care about.

$ time (cd libgloss && autoreconf -I$PWD -I$PWD/.. -I$PWD/../config)
real    0m8.313s
user    0m5.015s
sys     0m0.259s

we can see that killing excessive configure scripts & recursive makes helps
with compilation times too.

$ time (cd build; ../configure --host=bfin-elf; make -j4)
real    0m28.831s
user    0m34.828s
sys     0m23.093s

generating autotools is now slightly faster that compiling 8 copies of
newlib+libgloss :).  not that i'm advocating for changing anything :P.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-02-17  5:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-21 12:32 Matthew Joyce
2022-01-21 13:44 ` Corinna Vinschen
2022-01-21 15:02 ` R. Diez
2022-01-21 15:37   ` Joel Sherrill
2022-01-21 16:09     ` R. Diez
2022-01-21 22:09       ` Mike Frysinger
2022-01-21 23:08         ` Joel Sherrill
2022-01-22 21:20         ` R. Diez
2022-01-23  0:17           ` Joel Sherrill
2022-01-23 16:57             ` R. Diez
2022-01-26 10:19               ` Mike Frysinger
2022-01-30 22:22                 ` R. Diez
2022-01-23  7:29           ` Mike Frysinger
2022-01-26 10:02         ` Mike Frysinger
2022-02-17  5:18           ` Mike Frysinger [this message]
2022-02-17  6:56             ` Sebastian Huber
2022-02-20  9:51             ` R. Diez

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=Yg3apoTMTMojanx/@vapier \
    --to=vapier@gentoo.org \
    --cc=joel@rtems.org \
    --cc=matthew.joyce@embedded-brains.de \
    --cc=newlib@sourceware.org \
    --cc=rdiezmail-newlib@yahoo.de \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).