From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: lengths and stuff Date: Sun, 27 Dec 2020 10:52:42 -0800 (PST) Message-ID: <40d9718a-adcc-4ac8-a7dd-8b66270f40d3@default> References: <87o8ivumn5.fsf@telefonica.net>> <86sg7w39fh.fsf@163.com>> <83pn30pku5.fsf@gnu.org>> <86wnx8otoj.fsf@163.com>> <834kkbp9vr.fsf@gnu.org>> <87czyxuxw6.fsf@db48x.net>> <87y2hlt82w.fsf@db48x.net>> <87lfdlvsw4.fsf@logand.com>> <83h7o8ncly.fsf@gnu.org>> <87pn2wudab.fsf@db48x.net>> <87mty0c3m1.fsf@gnus.org>> <83czywnb86.fsf@gnu.org>> <87im8ob707.fsf@gnus.org>> <87eejcb6nx.fsf@gnus.org>> > <875z4ob5c9.fsf@gnus.org>> > <83mtxzly4f.fsf@gnu.org>> <87czyvsv3h.fsf_-_@db48x.net> <87v9cnqgjr.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38531"; mail-complaints-to="usenet@ciao.gmane.io" To: Tomas Hlavaty , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 27 19:53:39 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ktbAh-0009uQ-6y for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 19:53:39 +0100 Original-Received: from localhost ([::1]:34870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktbAg-0000UZ-8l for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 13:53:38 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktb9v-0008VM-2J for emacs-devel@gnu.org; Sun, 27 Dec 2020 13:52:51 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:56392) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktb9s-0007WD-RW for emacs-devel@gnu.org; Sun, 27 Dec 2020 13:52:50 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BRIZ2Ks114652; Sun, 27 Dec 2020 18:52:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=nr4+LL0XpzCb9C6gb/CAp0IMkXyeSjWKL2LufUSiQ10=; b=zkASAfsk93IAn+7fCm1kUF1zo8K+lTxj7S9jhaBElI+yZrykcQaycXLdfBiOmEwybvCl GF1cVcWoy4g+ncPHv11l8hZVq/SA3V2gEdLu8Xu9jWMt5MI+/48V2yFE3sb9hD3NWrYl Z0UEbsaOGNffc+NQIZ5Vf1GSJ6BUtOeLnqjZgOQ8T6Rnb2YReHrPNZS0p3lxId7f1qqL aYjGr3XZd1cvmkT21Fz96MXr75xAmEvA3YhPzvSbL4nf/EGCxG2XW4fouuSQsTd3/y1z oxm2v4m2xtGgSTrNRxo9DsM3QmNPjkjhJZ0KDeHsdL552XDa8+ZZmVhffmtabvzaPS4v 2A== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 35nvkqj2j2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 27 Dec 2020 18:52:46 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BRIZomh157954; Sun, 27 Dec 2020 18:52:45 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 35pexp49pg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 27 Dec 2020 18:52:45 +0000 Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0BRIqhHh010706; Sun, 27 Dec 2020 18:52:44 GMT In-Reply-To: <87v9cnqgjr.fsf@logand.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5095.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9847 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 spamscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012270118 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9847 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 bulkscore=0 adultscore=0 priorityscore=1501 malwarescore=0 impostorscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012270118 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.oracle.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.041, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:261915 Archived-At: > > And as I said, `length' is not so special in this regard. `map', > > `dolist', and others also provide the same rope to hang yourself with. >=20 > length is different than map and dolist. Everything that's not the same is different. > length is about a property of a list, namely about number of items. > map and dolist are about doing something with items of list. That's a quibble. Length is about doing something with the list elements: counting them. It's no more about a property of a list than is a function that checks all the element types or, like `member', finds an element that satisfies some condition. > Using length in a predicate is yet completely different and most likely > bad because to answer the predicate, traversing the whole list is wasted > time and energy. (lambda (xs) (=3D (length xs) 25)) ; need to count elts > > There are no specific functions that can be > > used to avoid the trap. >=20 > There are not, but there could be. No, not completely. The gotcha is much more general than the cases that could be "fixed" using the proposed predicates. > > I see no help offered by `length<' & compagnie. >=20 > The idea is that the intent is expressed in a way that can _guarantee_ > that useless length computation is avoided. There are plenty of other possibilities for uselessly invoking `length'. Probably the most typical one is neglecting to find the length only once and save it in a local variable. How much existing code (probably/hopefully mostly outside the core code) does that, instead of this? (let ((len (length xs))) ... len ...len ... len ...) A quick grep won't find places where code unwisely instead does ... (length xs) ... (length xs) ... (length xs). My guess is that those oblivious to the problem/gotcha do that much more often than they do a single `length' in a predicate that doesn't logically need to traverse the whole list. The point is that it's possible to misuse `length' (and `dolist' and `member' and ...). And no creation of `length<' etc. predicates helps. It fact, it can hurt, as I explained previously. =20 > > IOW, this stuff is best considered case by case. > > If a given case has no performance impact, then it's > > maybe better NOT to provide code that might give the > > impression that we're trying to avoid a particular > > performance penalty. Of course in middle cases, which > > might not be obvious to a human reader, we may need to > > make things clear explicitly. >=20 > But how do you know if it has or has not performance impact unless you > investigate each case? See above - this is best done case by case. As with all attempts to improve performance. Do it when it's appropriate/needed. If you don't know whether it's needed then don't do it. If it's really needed you'll know or you'll find out. Premature or otherwise misguided optimization essentially works against Occam's razor. Relevant/necessary optimization is just the opposite: it applies Occam's razor.=20 > > I wouldn't be in favor of systematically avoiding use > > of `length', as if all uses are poisonous. >=20 > In fact, it kind of is, especially when used in a predicate. No, it kind of isn't. Find the _actual_ places where the core Emacs code is _really_ problematic. See how many there are, compared to that shotgun-blast `grep'. Fix occurrences where the performance matters, i.e., those that are really problematic. End of story. `length<' & compagnie: YAGNI.