From xemacs-m  Mon May  5 23:26:18 1997
Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id XAA27743
	for <xemacs-beta@xemacs.org>; Mon, 5 May 1997 23:26:17 -0500 (CDT)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id VAA04801 for <xemacs-beta@xemacs.org>; Mon, 5 May 1997 21:26:17 -0700 (PDT)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id VAA02578; Mon, 5 May 1997 21:27:20 -0700
To: xemacs-beta@xemacs.org
Subject: Re: `mapcar' calling SUBRs directly
References: <kigenbomwik.fsf@jagor.srce.hr> 	<QQcnyy27061.199705031911@crystal.WonderWorks.COM> 	<kig207omjh5.fsf@jagor.srce.hr> 	<QQcnzb28042.199705031954@crystal.WonderWorks.COM> 	<kigyb9wl3ip.fsf@jagor.srce.hr> <QQcody26201.199705050337@crystal.WonderWorks.COM> <kig3es2imz6.fsf@jagor.srce.hr> <rvwwpd61x1.fsf@sdnp5.ucsd.edu>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
Mail-Copies-To: never
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: David Moore <dmoore@ucsd.edu>
Date: 05 May 1997 21:27:20 -0700
In-Reply-To: David Moore's message of 05 May 1997 14:31:54 -0700
Message-ID: <rvsp015ion.fsf@sdnp5.ucsd.edu>
Lines: 38
X-Mailer: Gnus v5.4.45/XEmacs 20.1

David Moore <dmoore@ucsd.edu> writes:

> There is a good way where you can profile very specifically what kinds
> of functions are given to mapcar1.  Then based on your profiling you may 
> decide that making mapcar1 more complicated, needing to be kept synched
> with other backtrace changes, and larger (affecting code cache) is worth 
> the change.  My gut reaction is that it won't be worth it.

BTW, this isn't totally fair.  Often people avoid mapcar/mapc in emacs
since it is slow.  An hour's worth of profiling mapcar1 showed very
little usage, probably at least partially due to this.


On the other hand in the common case, you can use a open coding approach
in the byte compiler (or a macro expansion before the byte compiler) to
give up to a 2x speedup on a simple mapcar ((mapcar 'cdr x) for
example), and up to 3x on mapc.  Note that these are speedups compared
to the overhead of mapcar/mapc.  So often the cost of the function being
applied will outweigh that, but it would be as efficient as the hand
written open coded loop.  Actually a good one would be quite a bit
faster than the traditional push/nreverse by using a queue.


I define common case to be application on a list (as opposed to
vector/string/etc) and the function is either a function symbol or a
lambda provided at compile time.  Ie, basically anything except a
variable.  Yes: (mapcar 'car l) (mapc (lambda (x) (prin1 x)) l)
No: (mapcar foo-var l)

You can probably also make the bytecompiler notice when the return value 
from a mapcar isn't used and turn it into a mapc.  A fair number of
people use this since they didn't want to load cl.el to get mapc.  But
this would take some work, since the bytecompiler knows about optimizing 
out side-effect free operations when the return value isn't used, but
this has potential side effects.  But you might be able to leverage on
that code.

-- david

