From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: pcase-memoize: equal first branch, yet different Date: Tue, 05 Mar 2013 10:41:16 -0500 Message-ID: References: <87hakv6tek.fsf@web.de> <8738warwtq.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1362498089 5428 80.91.229.3 (5 Mar 2013 15:41:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Mar 2013 15:41:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 05 16:41:52 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UCtzy-0008MU-DA for ged-emacs-devel@m.gmane.org; Tue, 05 Mar 2013 16:41:50 +0100 Original-Received: from localhost ([::1]:52863 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCtzc-0000wG-SZ for ged-emacs-devel@m.gmane.org; Tue, 05 Mar 2013 10:41:28 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCtza-0000w8-5d for emacs-devel@gnu.org; Tue, 05 Mar 2013 10:41:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCtzZ-0002YF-11 for emacs-devel@gnu.org; Tue, 05 Mar 2013 10:41:26 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:30834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCtzY-0002Y5-Sg for emacs-devel@gnu.org; Tue, 05 Mar 2013 10:41:24 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxLvL/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBrEfkA6NYYMpA4hhnBmBXoMV X-IPAS-Result: Av4EABK/CFFFxLvL/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBrEfkA6NYYMpA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="3076786" Original-Received: from 69-196-187-203.dsl.teksavvy.com (HELO pastel.home) ([69.196.187.203]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 05 Mar 2013 10:41:22 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id B69B96BCBE; Tue, 5 Mar 2013 10:41:16 -0500 (EST) In-Reply-To: <8738warwtq.fsf@lifelogs.com> (Ted Zlatanov's message of "Tue, 05 Mar 2013 04:59:45 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157530 Archived-At: > Would it make sense to implement some parts of `pcase' at the C level? No, that sounds like a nightmare. > As it becomes widely used, byte-compilation delays can also become > significant. pcase's expansion is not *that* slow. The problem is when it happens during evaluation in a loop, where macro expansion takes significantly more time (and memory) than the naive "try all patterns" would, so it can slow down evaluation by a large factor (think of macroexp--expand-all as a typical example: a large portion of the time is spent matching patterns, which means that it's worthwhile for the pcase macro to work hard to optimize the resulting code, but if the macro is re-expanded each time, this effort backfires). In reality, now that we have eager macroexpansion, the performance problems should be very rare (i.e. only happen in those rare cases like the one you posted, where the pcase is inside a chunk of code that's created at run time) and we could probably get away without memoizing. Stefan