From: Christopher Baines <mail@cbaines.net>
To: Simon Josefsson <simon@josefsson.org>
Cc: guix-devel@gnu.org
Subject: Re: Build dependency inflation (was: Re: Core-updates merge)
Date: Sat, 29 Apr 2023 10:32:47 +0200 [thread overview]
Message-ID: <87ildfw0fp.fsf@cbaines.net> (raw)
In-Reply-To: <87a5ytw6nd.fsf@kaka.sjd.se>
[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]
Simon Josefsson via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org> writes:
> [[PGP Signed Part:Undecided]]
> Andreas Enge <andreas@enge.fr> writes:
>
>> - Too much in Guix depends on too much else, which makes building things
>> needlessly entangled; in particular time zone data should not be referred
>> to by packages, but be loaded at runtime (Leo Famulari).
>
> This is an important open problem -- is there any way to attack this
> problem in a systematic way? I guess it is hard to understand which
> packages ends up depending on what since it is a large graph with long
> cycles, and also to understand which build depencies are essential and
> which are superficial, and thus consequently challenging to know where
> to start working to reduce build dependencies?
>
> I wonder if it is possible to graph all the build dependencies, and do
> something like a monte-carlo what-if simulation: randomly pick one
> build-dependency from the entire build-dependency graph and remove it,
> and recompute the graph. If the difference between these two graphs
> leads to a significantly lower total build computational cost than
> before, we may be on to something. My theory is that "true" build
> dependencies will show up in so many places that removing just one
> instance of it will not affect total build time. But "needless" build
> dependencies may occur just once or few times, and this approach would
> catch low-hanging fruit to work on. Maybe the simulation needs to be
> done on more than just removing one build-dependency, it could play
> what-if games removing two build-dependencies etc, or three random
> build-dependencies, and so on. Maybe my idea is flawed, and this will
> only lead to a list of build-dependencies that are impossible to get rid
> off anyway.
>
> Is there some other method to understand what build dependencies would
> be important to remove, to speed up total rebuild time?
>
> Maybe we could analyze how much of a particular build-dependency
> actually is used by a particular build? By looking into file-access
> patterns etc.
This is something I'd like to see incorporated in to qa.guix.gnu.org for
patch (and branch) review. While one off analysis is good, I think it's
most important to be able to look at changes and see how they change the
situation.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]
next prev parent reply other threads:[~2023-04-29 8:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-25 14:09 Core-updates merge Andreas Enge
2023-04-25 14:40 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-04-25 14:57 ` Katherine Cox-Buday
2023-04-25 19:27 ` Maxim Cournoyer
2023-04-25 15:31 ` Josselin Poiret
2023-04-25 16:09 ` Leo Famulari
2023-05-03 21:07 ` Ludovic Courtès
2023-04-27 17:56 ` Build dependency inflation (was: Re: Core-updates merge) Simon Josefsson via Development of GNU Guix and the GNU System distribution.
2023-04-27 23:28 ` bokr
2023-04-28 13:54 ` Simon Tournier
2023-05-03 21:10 ` Build dependency inflation Ludovic Courtès
2023-05-04 8:20 ` Simon Tournier
2023-04-29 8:32 ` Christopher Baines [this message]
2023-04-28 5:55 ` Core-updates merge John Kehayias
2023-04-28 14:17 ` Simon Tournier
2023-04-30 6:05 ` ocaml bootstrap (was Re: Core-updates merge) Efraim Flashner
2023-05-03 21:15 ` OCaml bootstrap Ludovic Courtès
2023-05-03 21:25 ` Julien Lepiller
2023-05-04 8:41 ` Simon Tournier
2023-05-04 10:01 ` Julien Lepiller
2023-05-04 18:26 ` Simon Tournier
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=87ildfw0fp.fsf@cbaines.net \
--to=mail@cbaines.net \
--cc=guix-devel@gnu.org \
--cc=simon@josefsson.org \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.