From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#50733: 28.0.1; project-find-regexp can block Emacs for a long time Date: Fri, 24 Sep 2021 21:49:35 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9447"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50733@debbugs.gnu.org, dgutov@yandex.ru, mardani29@yahoo.es To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 24 23:50:26 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 1mTt5L-0002Ab-JH for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Sep 2021 23:50:23 +0200 Original-Received: from localhost ([::1]:37996 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mTt5K-0003av-GB for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Sep 2021 17:50:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40498) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTt51-0003ac-EN for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 17:50:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47841) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mTt51-0002XF-7G for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 17:50:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mTt51-0007C5-5I for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 17:50:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Sep 2021 21:50:03 +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.163252018227597 (code B ref 50733); Fri, 24 Sep 2021 21:50:03 +0000 Original-Received: (at 50733) by debbugs.gnu.org; 24 Sep 2021 21:49:42 +0000 Original-Received: from localhost ([127.0.0.1]:59384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTt4g-0007B3-22 for submit@debbugs.gnu.org; Fri, 24 Sep 2021 17:49:42 -0400 Original-Received: from heytings.org ([95.142.160.155]:46584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTt4b-0007Ao-1X for 50733@debbugs.gnu.org; Fri, 24 Sep 2021 17:49:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1632520175; bh=BxeEnxgeVl54unkmomP916WJGygGDmBc+YTXj1LRn+c=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=wy5Tcb8A6q5VBrp/r+PmBN+nHWhZsL2FeL6pO0KGfu0xfGPy8mZMkO/6ECaGG/EIQ elGkU2EoXclW8TBzi9ofK0Hkapvrk1FTYbOR28vY6N5kb2OqJ+VPNwJfUEsWXos3m+ RU9M9pdRY3F5RtaSwXyQvMbjrwg1F6wlME7EgOCMf7L+4bsz5VHfeYUPv7Y7yuJ26H SrkKMlopHJpCWbgNNrBeG4NihYBdKbf+rIPZNIRsPFiBWpZx6i57KGjQ6lD+d7hMqX URXkA8qoKNCx3n8kpOqpPCByniRyRUrq6VD0r/XEblEV3bo9kOLXPULGkMV2TJC7wB 75SxkkWqyuY/Q== In-Reply-To: <83h7e9stbm.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" 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:215343 Archived-At: >> 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. > > (and generally think about gid as if it were a general-purpose > text-search utility). > Who told you that I'm talking about myself? I do not think of gid as a general-purpose text-search utility, but what most users want (and what project-find-regexp needs) is an efficient, easy to use and understand, predictable general-purpose text-search utility. ripgrep is one such utility, idutils is not. And, once again, ripgrep is, from a user point of view, as fast as or faster than idutils, and does not require any plumbing behind the scenes. 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? 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.