unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Sarah Morgensen <iskarian@mgsn.dev>
To: Taylan Kammer <taylan.kammer@gmail.com>
Cc: 50349@debbugs.gnu.org
Subject: bug#50349: [PATCH] packages: Add 'define-package' syntax.
Date: Sat, 04 Sep 2021 11:53:03 -0700	[thread overview]
Message-ID: <86v93gjhps.fsf@mgsn.dev> (raw)
In-Reply-To: <a93161dd-4425-f722-fa43-273ff9561916@gmail.com> (Taylan Kammer's message of "Sat, 4 Sep 2021 19:23:29 +0200 (1 hour, 11 minutes ago)")

Hi Taylan,

Taylan Kammer <taylan.kammer@gmail.com> writes:

> On 04.09.2021 16:44, Tobias Geerinckx-Rice wrote:
>> Taylan Kammer 写道:
>>> To me the most obvious thing to do seems
>>>
>>>   (define-package foo ...)  ;no explicit name needed
>>>
>>> to bind the variable 'foo' and use symbol->string for the name of the
>>> package, with the possibility to override the name like
>>>
>>>   (define-package foo (name "foobar") ...)
>>>
>>> which would bind the variable 'foo' to a package named "foobar".
>> 
>> Right, that's what I meant, and it's how I read bug #15284, and it looks remarkably like the form I use in my personal channels (and I'm sure I'm not the first! :-).
>> 
>> You're much better at the language/implementation side of things than I am, Taylan.  Would this negatively affect performance (including ‘guix pull’ compilation)?
>> 
>> Kind regards,
>> 
>> T G-R

I agree; if we added that magic, that's definitely how it should be.

>
> I'm flattered, but don't really know the answer, so I decided to attempt
> some sort of benchmark. :-P
>
> test1.scm uses the syntax-case macro, test2.scm just define-public.
>
> I don't actually import the Guix modules, so the (package ...) form isn't
> macro-expanded, regardless of whether it's used directly or results from
> expanding define-package.
>
> This way, the impact of define-package should dominate the time difference.
>
> The results are... interesting.  I started out with 256 definitions in the
> files, and the define-package one would take about 4.2s to compile while
> the regular one about 3.9s.  There was some jitter in the results though
> after running it several times so I thought, let's increase the number of
> packages to reduce noise.
>
> With 512 packages, the one using regular define-public takes a whole
> minute to compile, whereas the define-package one just ~14 seconds!
>
> So no idea what's going on there, and how the use of this macro in the
> actual (gnu packages ...) modules would affect performance. :-)

Thanks for running some benchmarks. Were both those latter runs with a
warm cache?

If so, is it possible that due to a compilation optimization, many of
the global symbol lookups only happen once with the define-package
macro?

If you were really interested, I suppose you could test with compilation
optimization off, but I'd be more interested in the performance impact
with (guix packages) imported.

--
Sarah




  reply	other threads:[~2021-09-04 18:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <15d01b32313f5f2f291b120597719ae92bd26acd.1630639896.git.iskarian@mgsn.dev>
     [not found] ` <757b7543b931335c3725264edfbc79c012aa10fc.camel@telenet.be>
2021-09-04 10:09   ` bug#50349: [PATCH] packages: Add 'define-package' syntax Tobias Geerinckx-Rice via Bug reports for GNU Guix
2021-09-04 14:29     ` Taylan Kammer
2021-09-04 14:44       ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2021-09-04 17:23         ` Taylan Kammer
2021-09-04 18:53           ` Sarah Morgensen [this message]
2021-09-04 21:01             ` Taylan Kammer
2021-09-04 23:17   ` Sarah Morgensen

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=86v93gjhps.fsf@mgsn.dev \
    --to=iskarian@mgsn.dev \
    --cc=50349@debbugs.gnu.org \
    --cc=taylan.kammer@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).