From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Juanma Barranquero" Newsgroups: gmane.emacs.devel Subject: Re: "simplifications" Date: Mon, 19 Nov 2007 11:56:35 +0100 Message-ID: References: <86ejem1pig.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1195469816 18884 80.91.229.12 (19 Nov 2007 10:56:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Nov 2007 10:56:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: "David Kastrup" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 19 11:57:02 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Iu4JE-0004Dx-W8 for ged-emacs-devel@m.gmane.org; Mon, 19 Nov 2007 11:56:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iu4J1-0002PI-8e for ged-emacs-devel@m.gmane.org; Mon, 19 Nov 2007 05:56:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iu4Iw-0002Jb-TJ for emacs-devel@gnu.org; Mon, 19 Nov 2007 05:56:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iu4Iv-0002Fz-EL for emacs-devel@gnu.org; Mon, 19 Nov 2007 05:56:38 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iu4Iv-0002Fi-5V for emacs-devel@gnu.org; Mon, 19 Nov 2007 05:56:37 -0500 Original-Received: from wa-out-1112.google.com ([209.85.146.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Iu4Iu-0005o9-Lq for emacs-devel@gnu.org; Mon, 19 Nov 2007 05:56:36 -0500 Original-Received: by wa-out-1112.google.com with SMTP id k34so1940884wah for ; Mon, 19 Nov 2007 02:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=B++jrZ8XHXbsuq4lj9V5vG7PBKo0avMFMMiUUx3EuTk=; b=R8Ev71cUF4x1Q+9gFsJVygnOoSBXxdUy0VqwPzzMAT041Al+xQRlzmoVCEfG8rFNDVgzwgQ6WmaBJ+YZ+KqbCQXeVFW5YsayyT9P/juNVL4pUKoRT055NbItylTeWMXf+eM9T/9ntY2UAxHM+2FREK7fYznH4UOTjUKqynPf6pA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mzUoXLD3lVyzC4FTUkChKNHCzsGdwDMpndnIbPvvHKUWdCGjNbmPlhJMpccgVErIxD1zltsfIkCCCSoR/LSC/6PYNCmjbWV+j/yKEnuUU1aOLMkDwj6RADQItwR4LOjSwreixn31CJvCo6FRN0HTPMxGciZFIK0HQC7YlgFqg6w= Original-Received: by 10.114.93.17 with SMTP id q17mr610350wab.1195469795604; Mon, 19 Nov 2007 02:56:35 -0800 (PST) Original-Received: by 10.114.168.11 with HTTP; Mon, 19 Nov 2007 02:56:35 -0800 (PST) In-Reply-To: <86ejem1pig.fsf@lola.quinscape.zz> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:83632 Archived-At: On Nov 19, 2007 11:46 AM, David Kastrup wrote: > Could people, before introducing such "optimizations", check the > bytecode? Some functions of ring.el already used c??r before my change. etc. > The former is _quite_ less efficient, so it is not a hot idea to use > it for data access primitives like the ring functions. Out of idle curiosity, I'd be really interested in knowing about uses of ring.el where that difference is going to be significant (i.e., we're speaking perhaps of thousands of ring function calls per second?). > Personally, I think that we should make the byte compiler optimize the > unnecessary binding away. But until that is the case, please don't > gratuitously replace (car (cdr ...)) with (cadr ...). I don't usually do it gratuitously, or I would've done it in a lot of places. I stumbled upon it, and certainly having code chock-full of (let ((hd (car (car ...))) (ln (car ...)) (vec (cdr (cdr ...)))) is not my idea of fun, or legible, or maintainable, or... you pick the word. Not that c??r is much of an improvement; we should be able to define accesor functions in the package (defsubst ring--vec (ring) (cdr (cdr ring))) and have the byte-compiler optimize them away. So, IMO, instead of bringing back the pain, let's enhance the byte-optimizer. But of course, you can revert the change if you dislike it that much. Juanma