From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nicolas Richard Newsgroups: gmane.emacs.help Subject: Re: looking-at-p slower than looking-at Date: Thu, 26 Nov 2015 14:37:32 +0100 Message-ID: <86ziy0khk3.fsf@members.fsf.org> References: <87r3js7e8l.fsf@linux-qg7d.fritz.box> <87y4dzv1b3.fsf@mbork.pl> <87vb8qb2q3.fsf_-_@ulb.ac.be> <87io4pzul5.fsf@mbork.pl> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448545250 17804 80.91.229.3 (26 Nov 2015 13:40:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Nov 2015 13:40:50 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, Barry Margolin To: Marcin Borkowski Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Nov 26 14:40:39 2015 Return-path: Envelope-to: geh-help-gnu-emacs@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 1a1wkz-0007WG-P3 for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Nov 2015 14:38:41 +0100 Original-Received: from localhost ([::1]:51282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1wl1-0004W5-S5 for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Nov 2015 08:38:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1wkh-0004TN-7v for help-gnu-emacs@gnu.org; Thu, 26 Nov 2015 08:38:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1wkd-0008KT-W4 for help-gnu-emacs@gnu.org; Thu, 26 Nov 2015 08:38:23 -0500 Original-Received: from mxin.ulb.ac.be ([164.15.128.112]:62861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1wkd-0008KM-Pp for help-gnu-emacs@gnu.org; Thu, 26 Nov 2015 08:38:19 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcEANAKV1akD4XH/2dsb2JhbABehH2/d4YPAoF9AQEBAQEBgQuENQEBBHkQCAMOCgklDwFHBhOILrovhBwBAQgCASCGVIR+iTkFjSKJNY8RhzQzjymDcmOEBT00hWABAQE Original-Received: from pno-math-199.ulb.ac.be (HELO Aurora) ([164.15.133.199]) by smtp.ulb.ac.be with ESMTP; 26 Nov 2015 14:37:37 +0100 User-agent: mu4e 0.9.15; emacs 25.1.50.1 In-reply-to: <87io4pzul5.fsf@mbork.pl> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 164.15.128.112 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:108228 Archived-At: Hi Marcin, Marcin Borkowski writes: > On 2015-11-25, at 14:58, Nicolas Richard wrote: > >> Marcin Borkowski writes: >> >>> You might also (depending on your use-case) want to use looking-at-p, >>> which is marginally slower than looking-at, but does not modify match >>> data. >> >> Why is it slower and how much slower is it ? I don't see how it can >> happen from its implementation: >> >> (defsubst looking-at-p (regexp) >> "\ >> Same as `looking-at' except this function does not change the match data." >> (let ((inhibit-changing-match-data t)) >> (looking-at regexp))) > > One more function call and one more variable binding. IMHO it /must/ be > slower, though I think the effect is negligible. I think there's not more function calls (in compiled code) since looking-at-p is a defsubst (i.e. gets inlined by the byte compiler). My own gut feeling is that setting inhibit-changing-match-data allows `looking-at' to take shortcuts, thus making it actually faster. > (setq foo "foo") > (benchmark 10000000 (looking-at foo)) > (benchmark 10000000 (looking-at-p foo)) benchmark is a function, so (looking-at(-p) foo) is evaluated first, returns nil, and that is what is given to benchmark as argument. IOW it's not benchmarking anything. You need to quote the form or use benchmark-run (or use M-x benchmark interactively). You could also use benchmark-run or benchmark-run-compiled instead (they are macros). I admit that it's not 100% clear from the docstring that the situation is different, since they both name call their argument FORM(S). Perhaps the macros have an argument named "BODY" instead of "FORMS". > (AFAIU, it is of utmost importance that you don't use literal stringso > in such a test, since then it is much more probable that GC will kick > in. Am I right?) I think the string litterals are read and "consed" only once. I'll try to convince you : (benchmark 3 '(message "%c" (incf (aref "a" 0)))) Running this with C-x C-e, I get : b c d in my *Message* buffer. Explanation : when you hit C-x C-e, emacs reads the sexp, thus translating it in a list of symbols, numbers and strings. At this point, "a" is thus a string in emacs memory. When the code is run, it modifies "a" inplace : (incf (aref "a" 0)) returns ?b (which is what we get in *Messages*) but modifies the string by side effect. So on the second run, the code gets the same string, which is now "b". Similarly for the third run, where the string is now "c". It would have been different had I done : (benchmark 3 '(message "%c" (incf (aref (string ?a) 0)))) because now the string "a" is re-constructed at run time everytime. Conclusion : I don't think you need to avoid string litterals to have less GC. Nicolas.