From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: elisp-benchmarks Date: Sat, 07 Dec 2019 09:27:49 -0800 Message-ID: <87d0d0f3l6.fsf@ericabrahamsen.net> References: <87tv6dfe3c.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="250323"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 07 18:28:33 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iddse-0012yr-KR for ged-emacs-devel@m.gmane.org; Sat, 07 Dec 2019 18:28:32 +0100 Original-Received: from localhost ([::1]:51896 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iddsd-0006yw-CW for ged-emacs-devel@m.gmane.org; Sat, 07 Dec 2019 12:28:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56343) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idds7-0006yp-JT for emacs-devel@gnu.org; Sat, 07 Dec 2019 12:28:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1idds4-000854-W3 for emacs-devel@gnu.org; Sat, 07 Dec 2019 12:27:59 -0500 Original-Received: from ericabrahamsen.net ([52.70.2.18]:57486 helo=mail.ericabrahamsen.net) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1idds4-00084O-SI for emacs-devel@gnu.org; Sat, 07 Dec 2019 12:27:56 -0500 Original-Received: from localhost (c-73-254-86-141.hsd1.wa.comcast.net [73.254.86.141]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 8A2CAFA08E; Sat, 7 Dec 2019 17:27:55 +0000 (UTC) In-Reply-To: (Andrea Corallo's message of "Fri, 06 Dec 2019 22:56:50 +0000") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 52.70.2.18 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243215 Archived-At: Andrea Corallo writes: > Eric Abrahamsen writes: > >> Andrea Corallo writes: >> >>> Hi, I attach the patch git formatted. I've also fixed two nits. >> >> Thanks for this package, and I'm looking forward to trying it out! I >> have one question at this point, which is that it seems somewhat >> limiting to require benchmarks to be placed into this package's own >> benchmarks/ directory. It seems like it would be nice to let them live >> anywhere, even if that means selecting them manually, rather than >> forcing a single location, as the package currently seems to do (unless >> I'm missing something?). For example, it might be nice to ship other >> packages with their own benchmark libraries, which would then be >> selectable somehow. What do you think? >> >> Thanks! >> Eric > > Hi Eric, > that's a very good point thanks for commenting. > > Actually with the current setup you could depose a benchmark in the > benchmarks folder that calls say some gnus function and define a test in > that way. Everything would work except the 'recompile'. Is the expectation that we'd actually be committing benchmarks to the benchmarks package? Or just dropping files into the installation directory? Both approaches seem a bit awkward -- for the former, you'd have to update the benchmark package whenever any other package updated its benchmarks. For the latter, when we update the benchmarks package, we'll lose any files we stuck in there manually. > I also like the idea of doing the other way around (defining benchmarks > and have them shipped with the package itself). This would be > potentially more elegant but I guess we should then have the > infrastructure to do that in Emacs and not just in ELPA. Is this > correct? > > Maybe you have in mind a different mechanism for this? I suppose the fanciest approach would be to do what ert does: provide a `elb-defbenchmark' macro that registers the benchmark in some central location, and allows the user to select which of the registered benchmarks to run. That might take more work than you'd had in mind, though. A simpler approach might be just to make the "working directory" argument of the interactive commands selectable with a prefix arg. Right now the prefix arg controls the selector -- maybe that could be a two-part selection? First directory, then string? Or something like that. At the very least, `elb-bench-directory' could be let-bound in a custom function. But making it a defconst really makes it feel like we shouldn't be doing that. Hope that's useful, Eric