From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Date: Tue, 02 Mar 2021 23:14:47 +0100 Message-ID: References: <87im69uzlt.fsf@mail.linkov.net> Reply-To: Theodor Thornhill Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1417"; mail-complaints-to="usenet@ciao.gmane.io" To: Dmitry Gutov , juri@linkov.net, 46859@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 02 23:15:18 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 1lHDIS-0000Ai-45 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Mar 2021 23:15:16 +0100 Original-Received: from localhost ([::1]:39400 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHDIR-0002n7-6a for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Mar 2021 17:15:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37886) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHDIF-0002mi-Bc for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 17:15:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42909) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHDIE-0003Su-0H for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 17:15:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lHDID-0000dZ-RF for bug-gnu-emacs@gnu.org; Tue, 02 Mar 2021 17:15:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Mar 2021 22:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46859 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 46859-submit@debbugs.gnu.org id=B46859.16147232932419 (code B ref 46859); Tue, 02 Mar 2021 22:15:01 +0000 Original-Received: (at 46859) by debbugs.gnu.org; 2 Mar 2021 22:14:53 +0000 Original-Received: from localhost ([127.0.0.1]:54455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHDI5-0000cx-6F for submit@debbugs.gnu.org; Tue, 02 Mar 2021 17:14:53 -0500 Original-Received: from out2.migadu.com ([188.165.223.204]:59215) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHDI2-0000co-FP for 46859@debbugs.gnu.org; Tue, 02 Mar 2021 17:14:51 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no 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:201245 Archived-At: Hi, Dmitry, Dmitry Gutov writes: > Hi Theodor, > > On 02.03.2021 23:13, Theodor Thornhill via Bug reports for GNU Emacs, > the Swiss army knife of text editors wrote: >> Yeah, maybe. However, without benchmarking, it is quite clear that >> adding your option is faster than my patch, since ripgrep has to search >> the whole minified file. I assume it short circuits, so that results >> are delivered quicker to emacs. Maybe this bug can be closed. > > Could you try benchmarking both approaches? > Ok, so here are some numbers: ;; With nothing (benchmark-run 10 (project-find-regexp "UrlChange")) ;; (11.748253 14 0.23526199999999997) ;; With -M 500 (benchmark-run 10 (project-find-regexp "UrlChange")) ;; (0.293626 0 0.0) ;; My patch (benchmark-run 10 (project-find-regexp "UrlChange")) ;; (1.230833 8 0.13783999999999996) > If the performance improvement from yours is at all comparable with > Juri's, I'm inclined to prefer that direction for reasons described in > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44983#71. > So, now it looks like my patch is an improvement, but not as much as limiting from ripgrep. I think that is because in my version, we still loop over the whole file, we just delete the contents so that we always show 500 columns. I'm interested in seeing if I could gain some more performance by short circuiting after the first iteration of a match on the same line. In my test scenario there are a lot of matches on the same huge line. What do you think? -- Theo