From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Spiers Subject: Re: proposal: defconst/defcustom org-tags-regexp Date: Sat, 1 Sep 2007 12:01:23 +0100 Message-ID: <20070901110123.GA32102@atlantic.linksys.moosehall> References: <20070716132118.GA28297@atlantic.linksys.moosehall> <56626b2502c1e0ead302243cb947b0b2@science.uva.nl> <20070720150513.GB28297@atlantic.linksys.moosehall> <931245f7aaa24436377e537552f1beab@science.uva.nl> Reply-To: Adam Spiers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IRQjJ-0005Ru-D9 for emacs-orgmode@gnu.org; Sat, 01 Sep 2007 07:01:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IRQjI-0005PY-56 for emacs-orgmode@gnu.org; Sat, 01 Sep 2007 07:01:28 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IRQjI-0005PM-15 for emacs-orgmode@gnu.org; Sat, 01 Sep 2007 07:01:28 -0400 Received: from mail.beimborn.com ([70.84.38.100]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IRQjH-0000iQ-G5 for emacs-orgmode@gnu.org; Sat, 01 Sep 2007 07:01:27 -0400 Content-Disposition: inline In-Reply-To: <931245f7aaa24436377e537552f1beab@science.uva.nl> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: org-mode mailing list Carsten Dominik (dominik@science.uva.nl) wrote: > On Jul 20, 2007, at 17:05, Adam Spiers wrote: > >On Wed, Jul 18, 2007 at 11:24:40PM +0200, Carsten Dominik wrote: > >>On Jul 16, 2007, at 15:21, Adam Spiers wrote: > >>>There seem to be a number of hardcoded regexps currently used for > >>>matching heading tags, all very similar looking, and typically > >>>something like: > >>> > >>> [ \t]*\\(:[[:alnum:]_@:]+:\\)?[ \t]*\\($\\|\r\\) > >>> > >>>Is there any reason why these shouldn't be factored out into a new > >>>defcustom org-tags-regexp? > >> > >>Well, one reason is efficiency. When a regular expression is a constant, > >>Emacs is able to cache the compiled version of the regular expression, > >>and this can speed up code that does a lot of matching quite a bit. > >>The token you show above is usually part of a larger string, so the full > >>regular expression would have to be make with concat and will therefore > >>be recompiled all the time. > > > >Right, point taken - like m//o in Perl. To be honest, it doesn't > >matter too much to me if it's defconst rather than defcustom. The > >main thing is that I can have tags starting with '<' :-) > > Hi Adam, > > this is not about defcustom or defconst, but about the question > of the regexp is built each time with concat, or not. Ah, I was assuming that the elisp interpreter was intelligent enough that if you did a concat of two or more constants, it would only build the regexp the first time, similar to m//o in Perl. Is that not the case? Or maybe it only performs this optimisation if you byte-compile? I found this in the elisp manual: -- Special Form: eval-when-compile body... This form marks BODY to be evaluated at compile time but not when the compiled program is loaded. The result of evaluation by the compiler becomes a constant which appears in the compiled program. If you load the source file, rather than compiling it, BODY is evaluated normally. If you have a constant that needs some calculation to produce, `eval-when-compile' can do that at compile-time. For example, (defvar my-regexp (eval-when-compile (regexp-opt '("aaa" "aba" "abb")))) Maybe I should practice what I preach and use mercurial to start an experimental branch to look at the impact on performance of doing this refactoring :-)