From: Daniel Littlewood <danielittlewood@gmail.com>
To: Evan Cooney <evancooney71@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Including code in a non-Guile language into Guix
Date: Thu, 31 Oct 2024 12:31:54 +0000 [thread overview]
Message-ID: <CAFDSbVcNt53e+Q7eBFeTB4jEM4Yaq1Ns35qMTRpSJmUZn_4DMA@mail.gmail.com> (raw)
In-Reply-To: <CA+NEbmQkSNLq+3_mzYwrK864mCsaaz6U9n4DpGrHT4KUK6wwuw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3470 bytes --]
Hi Evan,
Some guix commands are indeed quite slow. This has been the subject of
discussion on the mailing list previously. I found one example from a year
ago, but I guess there are others:
https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00085.html
That being said, I would recommend caution in your conclusions for two
reasons:
1. Most distributions are not a like-for-like comparison with Guix. The
only distro I would consider directly comparing with in terms of
performance would be NixOS. Installation of software on guix requires
strictly more work than, say, on Debian or Arch, because it provides more
guarantees than those distributions do in terms of reproducibility. Others
on the list can probably speak more to the details of why or how much
slower it should be expected to be. However, Guix *is* noticeably slower
than Nix is, so your observation is still correct.
2. Programme performance is a complex topic, and it is a common
misconception that programs written in C are always, or typically, faster
than counterparts in garbage-collected languages. This is not really true
in many cases, particularly when costs of development are considered.
I assume that having a C core, or splitting out parts of Guix into C, was
considered early on in development. After all it is kind of the point of
guile that it interfaces well with C. Other members of the lost may be able
to give the historical context.
Having said that, I wonder (and could not find out) whether there is
quantitative data on how fast/slow Guix is for common operations. If you
could do some timings of what you think "too slow" means (e.g. for a guix
pull, or guix shell PKG).
Some data from me, using Guix on a foreign distro (Debian)
guix pull ("38k new commits"): 21m45s
guix pull immediately after: 2m25s
guix shell emacs (fresh): 1m49s
guix shell emacs (cached): <1s
apt update: 2s
apt install emacs: 2s
nix-channel --update: 0m23s
nix shell -p emacs (fresh): 0m24s
nix-shell -p emacs (cached): 4s
The apt commands are really not a fair comparison. In particular I noticed
the Guix command had to pull in all dependencies, while apt seemingly had
everything readily available. Note that I did apt remove emacs before
installing, but nothing else.
I'm not sure whether the nix/guix comparisons are fair. I might have more
installed in Guix vs nix.
All the best,
Dan
On Thu, Oct 31, 2024, 06:50 Evan Cooney <evancooney71@gmail.com> wrote:
> Hello everyone,
>
> My name is Evan Cooney. I use GNU Guix but I'm pretty new to it, I'm also
> not a professional, I mostly program for fun and I'm mostly self-taught. I
> was watching some videos about software performance and optimization, which
> brought to mind that, at least on my computer, guix package commands
> (particularly search, install, and remove) run much slower than the
> equivalents on other distros I've used. I know that Guix is mainly written
> in Guile, but has much thought gone into optimizing these commands by
> rewriting some of the code in a more performance-oriented language like C?
> Guile is designed for interoperability with C code, and many other GNU
> programs (gcc, coreutils, gdb, bash, etc.) are written in C or similar
> languages. C is also more widely taught and known than Guile, so adding C
> might help bring developers to Guix. I would love to try to work on
> optimizing the performance of these commands and any help would
> be appreciated.
>
> Thanks,
> Evan Cooney
>
[-- Attachment #2: Type: text/html, Size: 4766 bytes --]
next prev parent reply other threads:[~2024-10-31 12:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-31 2:34 Including code in a non-Guile language into Guix Evan Cooney
2024-10-31 12:31 ` Daniel Littlewood [this message]
2024-10-31 14:15 ` Suhail Singh
2024-10-31 16:13 ` Ricardo Wurmus
2024-10-31 17:12 ` Suhail Singh
2024-10-31 16:15 ` Runciter via Development of GNU Guix and the GNU System distribution.
2024-10-31 16:23 ` Evan Cooney
2024-10-31 16:15 ` Ricardo Wurmus
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=CAFDSbVcNt53e+Q7eBFeTB4jEM4Yaq1Ns35qMTRpSJmUZn_4DMA@mail.gmail.com \
--to=danielittlewood@gmail.com \
--cc=evancooney71@gmail.com \
--cc=guix-devel@gnu.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 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).