From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: vc-git-grep vs project-find-regexp Date: Wed, 13 Sep 2023 00:05:45 +0300 Message-ID: <0a55db23-a568-6c4f-5366-d5920486a5d3@gutov.dev> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31342"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 To: =?UTF-8?Q?Nicol=c3=a1s_Ojeda_B=c3=a4r?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 12 23:06:46 2023 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 1qgAar-0007wS-D2 for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Sep 2023 23:06:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgAa3-0006Jv-5W; Tue, 12 Sep 2023 17:05:55 -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 ) id 1qgAa0-0006J1-TW for emacs-devel@gnu.org; Tue, 12 Sep 2023 17:05:53 -0400 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgAZy-00077V-8v for emacs-devel@gnu.org; Tue, 12 Sep 2023 17:05:52 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 10A7B5C01A9; Tue, 12 Sep 2023 17:05:48 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 12 Sep 2023 17:05:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1694552748; x=1694639148; bh=Nyyc6poepV1RijsIR2FTh1W2H9+TnaZ3eY5 47WUiDi0=; b=q7Qsfo6abfMpyWDNQJuSxKHnH/CZKmd9kI44ENdQIFPtg8FR/XN BZY8YjH2BTPnAxa6Rm7Ar2nYBkc1VA91bgjaCjt1IIIWo0HSZyu2yoNQ8tMHlhYJ Os0Uv3ag7VeaI2495TOTUTfZRdYTJOnDo/oU51dqYLnxCFUcLcyD4/rG1IqjTX14 J3XhYYy2cTclHI/m7qKuZ+YFgQX21HvOM+sM3T6K4WKH6ki26A6IAtUUsWgQt2oJ 2c6y1tfiCDrjoDQotzFZ5k7mRzSU8cF7aMCu11uMnR0cqaOGHBtcInGyBkwEPn/B 4p4BiG4VzYTsxYeV+GbMbZGgNhxRqBYS/tA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1694552748; x= 1694639148; bh=Nyyc6poepV1RijsIR2FTh1W2H9+TnaZ3eY547WUiDi0=; b=N kdSrU4khfqYbvI0sbwIuMWAycNyKtIRMaom0xnXNItudYT/4Z8p8Ie64haKIFFvT Nh0GRmvOhsd4e1XqEASJfDjPqm+izBurvescjIoZt/jOlvd2MhXEh692oRfSe8g6 C1MjvYe+GYPGedaISMlwGYT1PcQV1CaWXEklK1kjLbC058iZ84/3DSPn6HT87Lhb 89j9GIupIea6QmybR34ZOfL30SJSL+TO5idABp9OHIGnrYoeGWDiia5fLHAYfrxJ RkY2iiYimMuIABJhbCgd1gb8NlM/iqbCdWvOD8Y/8tE4RlFgJwjHHOnAb/3X3j34 g81BFvbvvxfcXjgp7qmkQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudeiiedgudehkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesth ekredttdefjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehg uhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpeefjeekvedvfeelfedufeevgeetvd evkeelvddtueetteefudefgfduieekffeileenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Sep 2023 17:05:47 -0400 (EDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.29; envelope-from=dmitry@gutov.dev; helo=out5-smtp.messagingengine.com X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.473, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310527 Archived-At: Hi! On 21/08/2023 18:29, Nicolás Ojeda Bär wrote: > While it seems to work well, project-find-regexp seems much slower > than vc-git-grep. After you execute the command, it pauses for what it > feels a long time (~2s in a medium-size codebase) before showing the > results. vc-git-grep on the other hand, starts displaying results > immediately. Have you tried measuring the time until Grep finishes too (not just until the output buffer is shown)? It's likely to be faster by that measure as well (for the moment), but that's not a certainty. Just curious how those compare as well. > Is there a good reason for this difference? The only visible > difference between both commands is that project-find-regexp's results > are displayed in a XREF buffer while vc-git-grep uses Grep mode. Xref uses a couple of abstractions to be able to show information from different sources. That has a cost, however. To be able to show the results buffer right away (while the search is in progress), requires more effort, including: - Listing files in a project asynchronously (so that intermediate reporting is possible) with performance comparable to the synchronous approach, simply is order not to regress on that speed (there is some progress, I think, in the latest messages in bug#64735). - To build on that, using some more advanced data structures than just lists for project files and search matches. Lazy sequences of futures, maybe. The ability to abort a search in progress will require some thought too: currently it comes for free with 'C-g' in Xref; in Grep it's one 'C-c C-c' away because the reference to the process is available; but if we do an opaque data structure, it could need an "abort" primitive as well.