From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...}) Date: Sat, 20 Apr 2019 20:16:25 +0300 Message-ID: <83y344a97a.fsf@gnu.org> References: <8736md90v0.fsf@gmail.com> <83lg05b1jk.fsf@gnu.org> <87lg047h9n.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="186232"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Alex Gramiak Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 20 19:29:48 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.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hHtoC-000mGB-1p for ged-emacs-devel@m.gmane.org; Sat, 20 Apr 2019 19:29:48 +0200 Original-Received: from localhost ([127.0.0.1]:43647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHtoA-0000vb-Uf for ged-emacs-devel@m.gmane.org; Sat, 20 Apr 2019 13:29:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHto3-0000v8-VN for emacs-devel@gnu.org; Sat, 20 Apr 2019 13:29:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHtba-0000k7-B7; Sat, 20 Apr 2019 13:16:46 -0400 Original-Received: from [176.228.60.248] (port=1884 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hHtbZ-0003qF-ED; Sat, 20 Apr 2019 13:16:46 -0400 In-reply-to: <87lg047h9n.fsf@gmail.com> (message from Alex Gramiak on Sat, 20 Apr 2019 10:50:28 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:235703 Archived-At: > From: Alex Gramiak > Cc: emacs-devel@gnu.org > Date: Sat, 20 Apr 2019 10:50:28 -0600 > > > Doesn't seq.el already provide this functionality? > > Some, but not all. I don't see a vector-partition equivalent > (seq-partition is different), or a vector-index equivalent > (seq-find/cl-find return the element instead of the index, and is ~10x > slower). Isn't seq-position the equivalent of vector-index? Anyway, if some algorithms are missing from seq.el, maybe we should just add them there instead of starting an entirely new family of primitives? > > As for speed, did you have any application where the speed of the Lisp > > implementation was inadequate? > > For vector-memq, the Lisp implementations almost disallow it from being > used over memq/lists. The equivalent in seq.el, seq-position, is ~100x > slower for smaller vectors and ~200x for larger (500 elements) vectors. The factors don't really answer my question. The question was whether some real-life application that uses seq.el is so slow that moving them to C is necessary. IOW, the question was about absolute times, not relative times. If you can describe such use cases, I'd like to discuss them with the participation of seq.el's maintainer first. And if we eventually decide that some special cases do require to be coded in C, I think we'd prefer calling them from seq.el, not directly. Otherwise, why have seq.el at all? > The main two I care about here are vector-memq/vector-member. Please tell why in more detail. Thanks.