unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Simon Tournier <zimon.toutoune@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>,  Andreas Enge <andreas@enge.fr>
Subject: Re: How many bytes do we add (closure of guix) when adding one new package?
Date: Fri, 26 May 2023 18:21:34 +0200	[thread overview]
Message-ID: <87ttvzhxm9.fsf@gnu.org> (raw)
In-Reply-To: <87r0r4uv4x.fsf@gmail.com> (Simon Tournier's message of "Thu, 25 May 2023 20:24:30 +0200")

Hello!

Thanks for the detailed analysis!

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> Conclusions:
>
>  1. the addition of one package leads to an increase of ~ 12 KiB
>
>  2. the core of Guix is about ~ 62 MiB
>
>  3. doubling the number of packages is doubling the size to download at
>     “guix pull” time.

I agree that .go files are quite big (.scm files as well, but we’ve
improved information density somewhat by removing input labels :-)).

The size of .go files went down when we switch to the baseline compiler
(aka. -O1):

  https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00071.html

That thread has ideas of things to do to further reduce .go size.

Download size has to be treated separately though.  For example, ‘git
pull’ doesn’t redownload all of the repo or directory, and it uses
compression heavily.  Thus, a few hundred bytes of additional .scm text
translate in less than that.

As for the rest, download size can be reduced for example by choosing a
content-address transport, like something based on ERIS.

I think we must look precisely at what we want to optimize—on-disk size,
or bandwidth requirement, in particular—and look at the whole solution
space.

My 2¢!

Ludo’.


  reply	other threads:[~2023-05-26 16:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ZEZWS/h9xa/ZX3/E@jurong>
     [not found] ` <875y9jzl9m.fsf@gnu.org>
     [not found]   ` <874jot19fd.fsf_-_@gnu.org>
     [not found]     ` <87fs7rvv5s.fsf_-_@gnu.org>
     [not found]       ` <ZGj3hGKGwu3mQklT@jurong>
     [not found]         ` <878rddooy4.fsf@gnu.org>
2023-05-25 18:24           ` How many bytes do we add (closure of guix) when adding one new package? Simon Tournier
2023-05-26 16:21             ` Ludovic Courtès [this message]
2023-05-30 12:10               ` Simon Tournier
2023-05-30 19:10                 ` Csepp
2023-05-31  8:05                   ` Faster “guix search” (was Re: How many bytes do we add (closure of guix) when adding one new package?) Simon Tournier
2023-05-31 11:10                     ` Csepp
2023-05-31 11:55                       ` Attila Lendvai
2023-05-30 20:55                 ` How many bytes do we add (closure of guix) when adding one new package? Jack Hill
2023-05-31  8:27                   ` Simon Tournier
2023-05-31 12:47                     ` Guillaume Le Vaillant

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

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ttvzhxm9.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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).