From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: return first element in list with certain property Date: Tue, 21 Nov 2017 11:26:35 -0800 (PST) Message-ID: <31dcbfa2-8d13-463c-bbab-fe5109bbab37@default> References: <8660a60zjn.fsf@zoho.com> <87mv3gzndx.fsf@ericabrahamsen.net> <86ine4y7jy.fsf@zoho.com> <874lpozk0y.fsf@ericabrahamsen.net> <8660a4xuou.fsf@zoho.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1511292430 7805 195.159.176.226 (21 Nov 2017 19:27:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Nov 2017 19:27:10 +0000 (UTC) To: Philipp Stephani , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Nov 21 20:27:06 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHECF-0001ZQ-IM for geh-help-gnu-emacs@m.gmane.org; Tue, 21 Nov 2017 20:27:03 +0100 Original-Received: from localhost ([::1]:36194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHECM-0001RH-Ra for geh-help-gnu-emacs@m.gmane.org; Tue, 21 Nov 2017 14:27:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHEBv-0001P3-JK for help-gnu-emacs@gnu.org; Tue, 21 Nov 2017 14:26:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHEBs-0008Qo-F7 for help-gnu-emacs@gnu.org; Tue, 21 Nov 2017 14:26:43 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:28523) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eHEBs-0008Qc-6O for help-gnu-emacs@gnu.org; Tue, 21 Nov 2017 14:26:40 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vALJQboq009441 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Nov 2017 19:26:38 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vALJQb8n006971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Nov 2017 19:26:37 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vALJQaTB016262; Tue, 21 Nov 2017 19:26:37 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4615.0 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:115036 Archived-At: > Please consider Knuth's statement about premature optimization. Until > your users have actually complained about the speed of your product and y= ou > have benchmarked it and isolated cl-find-if as the culprit, there's no ne= ed to > micro-optimize. 100% agreement. > Presumably cl-find-if has performed two iterations for years > or decades without anybody being bothered enough to improve it. "Presumably ..." No. Yes, cl.el has been here for a long time. But that doesn't mean that everything in it is implemented as well as it could be. It was put together in a fairly short time, and it has _not_ had super heavy use over the years (that's my guess). And yes, Emacs lisp use (including of CL emulation) is mostly for Emacs, and most use cases do not involve things that need high performance. The number of cases where `cl-find' has actually been used on very large lists is likely not so high. Looking at the code, it seems that it would not be difficult to improve this aspect, providing just a single traversal. For the list case it could just use the catch-throw idiom, for example. So yes, not choosing to use `cl-find' in your Emacs-Lisp code just because it traverses the list twice is silly and is most likely premature optimization. But fixing the `cl-find' implementation so that it does not gratuitously traverse the list twice might not be silly. As those tests communicated here so far have shown, `cl-find' is anyway performant - no doubt partly because `elt' has a C implementation. Still, the double traversal is gratuitous, and `cl-find' would be faster without it. (Do I personally care about how fast it is? Not really.)