From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: master 289000e: Merge branch 'feature/native-comp' into trunk Date: Wed, 28 Apr 2021 17:10:27 +0200 Message-ID: <87r1iula1o.fsf@telefonica.net> References: <831rayktot.fsf@gnu.org> <83v989jmuc.fsf@gnu.org> <83czuhjh0r.fsf@gnu.org> <87eeexm56d.fsf@telefonica.net> <875z08n79y.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29599"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:PMHPkF23kD3p/ayidEypUDJ0UmU= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 28 18:16:16 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lbmrI-0007bG-Ch for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Apr 2021 18:16:16 +0200 Original-Received: from localhost ([::1]:50340 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lbmrH-00062i-CC for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Apr 2021 12:16:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbm1S-0000TY-M0 for emacs-devel@gnu.org; Wed, 28 Apr 2021 11:22:42 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:49338) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbm1O-0003RC-C2 for emacs-devel@gnu.org; Wed, 28 Apr 2021 11:22:41 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lblpf-0008b6-Vu for emacs-devel@gnu.org; Wed, 28 Apr 2021 17:10:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268573 Archived-At: Alan Mackenzie writes: > OK, I see what you mean, now. Currently, if I understand correctly, > regexps are compiled into an interpreted language at runtime, and they > are stored in a (fairly large) cache indexed by the regexp string. > > When would you compile the regexps into native code? For constant > regexps this can be done at build time, but there are regexps > constructed at run time in Emacs. This compilation of regexps at run > time might negate the advantages in speed that the complation would > otherwise bring. On simple strategy is to compile the regexps by explicit request of the code author, he decides when a regexp is worth the extra work of turning it into native code. As per the regexps built at run time, an ordinary JIT compiler would have no problem with them at all, but Emacs JIT engine puts the code it generates into shared libraries. I don't know if it also supports generating and using code directly in memory.