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

-- 
Taylan