Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with SMTP id p3L8bPQm005790 for ; Thu, 21 Apr 2011 10:37:26 +0200 Received: (qmail 15282 invoked by alias); 21 Apr 2011 08:37:20 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 21 Apr 2011 08:37:19 -0000 Received: from relay2.uni-heidelberg.de (EHLO relay2.uni-heidelberg.de) [129.206.210.211] by mx0.gmx.net (mx024) with SMTP; 21 Apr 2011 10:37:19 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id p3L8ZH7Y018988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2011 10:35:18 +0200 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id p3L8G5pF005520; Thu, 21 Apr 2011 10:35:17 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1234254 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Thu, 21 Apr 2011 10:35:17 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id p3L8ZG8X006236 for ; Thu, 21 Apr 2011 10:35:17 +0200 Received: from ueamailgate02.uea.ac.uk (ueamailgate02.uea.ac.uk [139.222.131.185]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id p3L8Z3Ub004929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Apr 2011 10:35:07 +0200 Received: from ueams01.uea.ac.uk (ueams01.uea.ac.uk [139.222.131.78]) by ueamailgate02.uea.ac.uk (8.13.8/8.13.8) with ESMTP id p3L8Z1FN019299; Thu, 21 Apr 2011 09:35:01 +0100 Received: from [139.222.114.131] by ueams01.uea.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1QCpLk-0002RZ-5R; Thu, 21 Apr 2011 09:34:56 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 References: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN, outgoing) X-CanIt-Geo: ip=139.222.131.78; country=GB; region=I9; city=Norwich; latitude=52.6333; longitude=1.3000; http://maps.google.com/maps?q=52.6333,1.3000&z=6 X-CanItPRO-Stream: UEA:outgoing (inherits from UEA:default,base:default) X-Canit-Stats-ID: 75212252 - 1eaa4b258a09 - 20110421 X-Scanned-By: CanIt (www . roaringpenguin . com) on 139.222.131.185 Message-ID: <4DAFEC37.9070505@morningstar2.co.uk> Date: Thu, 21 Apr 2011 09:35:03 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Joseph Wright Subject: Re: Efficiency v correctness in \cs_new:Npn To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (eXpurgate); Detail=5D7Q89H36p4yCuwxJv6KY7fMyn81QvEOFxBqrGwRlwMuKaxMJrz+F0nUgP+FFlqteZ+Zj 1myiZD9b6raYeHJzATnFo2WSJxmswq31LlSHPG6jfIJxinoJ1k4ozyfXPluheXj+xwNQqb25jC+a AOTcQ83AmvRTX5BckrC6uJwr+4o4In9KmVHFA3y0y7TYLeR4H5zoEdEEv807hItUbKHEg==V1; X-Resent-By: Forwarder X-Resent-For: rainer.schoepf@gmx.net X-Resent-To: rainer@rainer-schoepf.de Status: R X-Status: X-Keywords: X-UID: 6722 On 21/04/2011 09:27, Will Robertson wrote: > Hi, > > Bruno has raised an issue [1] with \cs_new:Npn: it's slow. > > [1]: http://github.com/latex3/svn-mirror/issues/17 > > Around the time when the "\cs_" prefix was first introduced, Morten added a check to \cs_new:Npn to ensure you weren't trying to use it to define a command with a ":D" suffix, as they should be reserved for engine primitives. > > This seemed like a good idea at the time, but considering how often \cs_new:Npn is used in expl3, it has a definite performance hit to performing this check each and every time it's used. > > We'd like to propose dropping this check and moving it into the currently defunct l3chk module, which is designed to "switch on" these optional checks that are nice in theory but not efficient in practise. (l3chk hasn't been maintained so much but at some point I'd like to revive it.) > > Any thoughts for or against this idea? I am in favour of this: checking for 'free' functions should really just do that (after all, there are _lots_ of other mistakes that could be made that are not checked). On the l3chk module, I think it is clear we need to overhaul the 'checking' guards and so forth for a 'slower but more careful' version of expl3 for debugging. This check would fit in there, I guess. -- Joseph Wright