From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#50733: 28.0.1; project-find-regexp can block Emacs for a long time Date: Sat, 25 Sep 2021 09:26:06 +0300 Message-ID: <835yuprx1d.fsf@gnu.org> References: <03aa81b5-6077-c35c-1a5f-ec4d867b59ac@yandex.ru> <63300a34-e487-02d1-c182-2b84438654d7@yandex.ru> <83k0j6trau.fsf@gnu.org> <838rzmtf00.fsf@gnu.org> <83sfxurr67.fsf@gnu.org> <83ilypsw31.fsf@gnu.org> <83h7e9stbm.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17853"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50733@debbugs.gnu.org, dgutov@yandex.ru, mardani29@yahoo.es To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 25 08:41:47 2021 Return-path: 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 ) id 1mU1Nb-0004RH-04 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Sep 2021 08:41:47 +0200 Original-Received: from localhost ([::1]:35464 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mU1NZ-0004qF-0u for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Sep 2021 02:41:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57050) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mU19K-0001I4-9O for bug-gnu-emacs@gnu.org; Sat, 25 Sep 2021 02:27:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48588) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mU19K-0008SH-1k for bug-gnu-emacs@gnu.org; Sat, 25 Sep 2021 02:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mU19J-0005BA-SC for bug-gnu-emacs@gnu.org; Sat, 25 Sep 2021 02:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Sep 2021 06:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50733 X-GNU-PR-Package: emacs Original-Received: via spool by 50733-submit@debbugs.gnu.org id=B50733.163255118319851 (code B ref 50733); Sat, 25 Sep 2021 06:27:01 +0000 Original-Received: (at 50733) by debbugs.gnu.org; 25 Sep 2021 06:26:23 +0000 Original-Received: from localhost ([127.0.0.1]:60134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mU18d-0005A4-TK for submit@debbugs.gnu.org; Sat, 25 Sep 2021 02:26:23 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mU18a-00059j-Pz for 50733@debbugs.gnu.org; Sat, 25 Sep 2021 02:26:18 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60822) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mU18V-0007mV-3r; Sat, 25 Sep 2021 02:26:11 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3194 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mU18U-0007LP-HD; Sat, 25 Sep 2021 02:26:10 -0400 In-Reply-To: (message from Gregory Heytings on Fri, 24 Sep 2021 21:49:35 +0000) 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:215416 Archived-At: > Date: Fri, 24 Sep 2021 21:49:35 +0000 > From: Gregory Heytings > cc: 50733@debbugs.gnu.org, dgutov@yandex.ru, mardani29@yahoo.es > > >> Hint: read again, and look closer. gid returns some matches in > >> comments, some not. For no apparent reason. > > > > Of course, there is a reason, you just don't understand it > > Who told you that I'm talking about myself? FWIW, I understand the > reason, but it's a completely non-apparent one, that isn't documented > anywhere. And it's not one that would make sense to most users. What would you like to document about it? that sometimes false positives do happen? Does any other similar utility ever does something like that in its documentation? Dealing with false positives is for the users of the utility, because only they know which ones are false. Or are you saying that having N false positive is somehow worse than having M > N false positive, because some theoretical users might not understand why they see some of the N false positives but not the others? (I say "theoretical" because evidently you didn't have a problem understanding the reason.) > Out of curiosity, because of your "it doesn't scale" remark, I just > compared the efficiency of ripgrep and idutils on the latest Linux kernel > tarball (1.4 GB in 78464 files): > > mkid takes 31 seconds > > rg O_CREAT takes 0.18 seconds > gid O_CREAT takes 0.02 seconds > rg O.?CREAT takes 0.18 seconds > gid O.?CREAT takes 0.93 seconds > rg O.*CREAT takes 0.19 seconds > gid O.*CREAT takes 1.73 seconds > > Isn't idutils the one that doesn't scale? No. You compare apples with oranges. > The only case in which idutils is faster (if one does not take the time > that was spent to build the database into account, and if one considers > that it's okay to ignore some matches in comments) is a plain identifier; > from a user viewpoint getting an answer in 0.2 seconds on such a big code > base is as good as getting an answer in 0.02 seconds. It's slower, much > slower in all other cases, whenever a regexp is used --- which is what > project-find-regexp is all about. See what I mean? Even when it's better, it's worse. Perfect reasoning.