Hi Taylan, Taylan Kammer <taylan.kam...@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