From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Ihor Radchenko <yantar92@posteo.net>
Newsgroups: gmane.emacs.bugs
Subject: bug#63225: Compiling regexp patterns (and REGEXP_CACHE_SIZE in
 search.c)
Date: Tue, 02 May 2023 17:58:01 +0000
Message-ID: <87wn1q62fq.fsf@localhost>
References: <87ttwvgp4s.fsf@localhost>
 <63882A45-BD02-40D5-92FA-70175267BA3B@acm.org> <83sfcen4bl.fsf@gnu.org>
 <2CE6FE12-70E4-49D2-8C06-1F2ADF2A6E39@gmail.com> <83r0rymyid.fsf@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="22868"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: 63225@debbugs.gnu.org,
 Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= <mattias.engdegard@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 02 19:56:22 2023
Return-path: <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>
Envelope-to: geb-bug-gnu-emacs@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 <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>)
	id 1ptuEg-0005en-0H
	for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 May 2023 19:56:22 +0200
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <bug-gnu-emacs-bounces@gnu.org>)
	id 1ptuEN-0007N2-Vr; Tue, 02 May 2023 13:56:04 -0400
Original-Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>)
 id 1ptuEM-0007Mu-P9
 for bug-gnu-emacs@gnu.org; Tue, 02 May 2023 13:56:02 -0400
Original-Received: from debbugs.gnu.org ([209.51.188.43])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>)
 id 1ptuEM-0003Yx-Cr
 for bug-gnu-emacs@gnu.org; Tue, 02 May 2023 13:56:02 -0400
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
 (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1ptuEM-0003y8-8a
 for bug-gnu-emacs@gnu.org; Tue, 02 May 2023 13:56:02 -0400
X-Loop: help-debbugs@gnu.org
Resent-From: Ihor Radchenko <yantar92@posteo.net>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Tue, 02 May 2023 17:56:02 +0000
Resent-Message-ID: <handler.63225.B63225.168305010314999@debbugs.gnu.org>
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 63225
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
Original-Received: via spool by 63225-submit@debbugs.gnu.org id=B63225.168305010314999
 (code B ref 63225); Tue, 02 May 2023 17:56:02 +0000
Original-Received: (at 63225) by debbugs.gnu.org; 2 May 2023 17:55:03 +0000
Original-Received: from localhost ([127.0.0.1]:44985 helo=debbugs.gnu.org)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
 id 1ptuDP-0003to-0E
 for submit@debbugs.gnu.org; Tue, 02 May 2023 13:55:03 -0400
Original-Received: from mout01.posteo.de ([185.67.36.65]:48209)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@posteo.net>) id 1ptuDM-0003sg-TZ
 for 63225@debbugs.gnu.org; Tue, 02 May 2023 13:55:02 -0400
Original-Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 184E424034C
 for <63225@debbugs.gnu.org>; Tue,  2 May 2023 19:54:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1683050095; bh=HazWvOwphNtazXRuixJH9DO3NwvcFTJEUMHfayWspJk=;
 h=From:To:Cc:Subject:Date:From;
 b=mmbR+12+njmRWZJx7oYOj4uI1mvklCcit3NlDnn7ljucAbtWxkNEdq9ALnb4VkxW9
 dVl7icdGQvk2xQlyEmHZHjln4mNSGSCgTKZdEbEk6hH1eewpjZqs2Xr5ngLgYr+quF
 EeDDjl8Kw85vbeuPa7V8wp13v4j0IVDqxCv2KHf2bB5OvGuzKdoGb33N40fjD64wk6
 fekfeOofhV57T6JVS/GFNxFg/zdT444wXY541+9gXPt2IX1NndhPhN5czW/BFw6LrG
 HF5x4gS8n/AsSFfM6z1mkHtOfPZRnXsymMfhsbhFodLWc4bNFM1y7hiVEM8PCI+rej
 cBQcUJA/mWiLw==
Original-Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4Q9nly3Mc5z9rxB;
 Tue,  2 May 2023 19:54:54 +0200 (CEST)
In-Reply-To: <83r0rymyid.fsf@gnu.org>
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
X-BeenThere: bug-gnu-emacs@gnu.org
List-Id: "Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-gnu-emacs>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=subscribe>
Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org
Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org
Xref: news.gmane.io gmane.emacs.bugs:260951
Archived-At: <http://permalink.gmane.org/gmane.emacs.bugs/260951>

Eli Zaretskii <eliz@gnu.org> writes:

>> These patches were not proposed for inclusion in Emacs but to help Ihor solve his problems in other ways. Sorry about not making it clear.
>
> I thought you said that exposing the cache size to Lisp _was_ the way
> to better support Lisp programs that need to use huge amounts of
> regular expressions, no?  If not, how will those patches be able to
> help Ihor, given that he wants to solve them in Emacs?

Well. My original simplistic proposal was to increase REGEXP_CACHE_SIZE.
Exposing this to Elisp certainly gives more flexibility, but also has
downsides (due to linear search across the regexp cache).
Ultimately, compiled regexp objects should be much more universal and
will not require extensive benchmarking to balance between regexp
compilation and increasing regexp cache search latency. But adding a new
Elisp object type is a big deal.

For now, we should probably study what is going on in my use case more
generally and maybe figure out if some alternative approach could be
better. If a simple solution will do, it may be good enough.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>