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#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Date: Sat, 06 Mar 2021 22:47:45 +0000 Message-ID: <7de1aeec52841199faed@heytings.org> References: <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@heytings.org> <87y2f42ex5.fsf@mail.linkov.net> <4119ea30552873ab9870@heytings.org> <83eegvk2u0.fsf@gnu.org> <9cff0f8894658f3b50c8@heytings.org> <83y2f3huz2.fsf@gnu.org> <9cff0f88942d4103c685@heytings.org> <83mtvjhrzj.fsf@gnu.org> <9cff0f889435d8d03313@heytings.org> <834khq266r.fsf@gnu.org> <9cff0f8894ab45713d12@heytings.org> <16ac41d4-5718-0cec-a68b-4abcc736ee4a@yandex.ru> <109276c6-30fb-b1ca-cafa-48a15710099b@yandex.ru> <7de1aeec520f4204be5b@heytings.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="23019"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46859@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 06 23:48:10 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 1lIfiT-0005tI-Km for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Mar 2021 23:48:09 +0100 Original-Received: from localhost ([::1]:59578 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIfiS-0005iV-Nl for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Mar 2021 17:48:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36408) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIfiM-0005gq-HM for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 17:48:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55186) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lIfiM-0002pd-8p for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 17:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lIfiM-0004aW-6p for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 17:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Mar 2021 22:48:02 +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.161507086817617 (code B ref 46859); Sat, 06 Mar 2021 22:48:02 +0000 Original-Received: (at 46859) by debbugs.gnu.org; 6 Mar 2021 22:47:48 +0000 Original-Received: from localhost ([127.0.0.1]:38499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIfi8-0004a3-10 for submit@debbugs.gnu.org; Sat, 06 Mar 2021 17:47:48 -0500 Original-Received: from heytings.org ([95.142.160.155]:46090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIfi6-0004Zv-T4 for 46859@debbugs.gnu.org; Sat, 06 Mar 2021 17:47:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1615070865; bh=0bU0utP3jUKMI50MOVEwhQ5yj77QgsjOkNq2tb3fBQ8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=xVCKpweq7daXJeRurPbuzXF+GQIAN5OYbzpvLiwqVUbom2N8RwER1UmEefbkFyT70 l1+aCi28/1EXgG18MDuuDzh+e24GkSVM8HNiC/R78JlasbpSsB8X4+T3pTR92/MpJl /Fxk+Ik7nBaSPXbU8xxPGimjgUepWtFkW9+tM/tBtL7lOOHDRdj/c7NIZAbVhLBGaz iItYGRxybAxbahGaw+k3h5xvhXf2zXS7xhACDGIY+NuFciR+uSCxjFjO7z2iV34uwS hgQx/TxxLM0UDHz5eXoM49oFiZqtSiCajCH4fVm0bScpbr0+QkanIpFXF3ebfXxMB0 2SkpE5JAs9mXw== In-Reply-To: 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:201695 Archived-At: >>> Also: grepping for that kind of regexp is noticeably slower than >>> grepping for 'file'. Or even '.file'. Like 85ms vs 7ms slower. >> >> Well, the bug report mentioned delays of 3-4 seconds on files with very >> long lines, so I'd guess that 85 ms is a pretty reasonable speed... > > We do want fast searches to remain fast, too. > > I got that 85ms timing when searching just one file. A project can often > contain thousands of files. > I just did a number of timing tests. The timings were done in a shell, on a fresh clone of the Emacs repository, which contains ~5000 files, and in which one searches for the 43 occurrences of "expose_frame". The timings are (in seconds): with GNU grep (version 3.6): 0.124 | "find -name '.?*' -prune -o -type f -print | xargs grep -i -snHE expose_frame" 0.178 | "find -name '.?*' -prune -o -type f -print | xargs grep -i -snobHE '.{0,50}expose_frame.{0,50}'" 0.253 | "find -name '.?*' -prune -o -type f -print | xargs grep -i -snobHE '.{0,80}expose_frame.{0,80}'" 0.325 | "find -name '.?*' -prune -o -type f -print | xargs grep -i -snobHE '.{0,100}expose_frame.{0,100}'" with ripgrep (version 12.1.1): 0.045 | "find -name '.?*' -prune -o -type f -print | xargs rg -i -nH --no-messages expose_frame" 0.079 | "find -name '.?*' -prune -o -type f -print | xargs rg -i -nobH --no-messages '.{0,50}expose_frame.{0,50}'" 0.109 | "find -name '.?*' -prune -o -type f -print | xargs rg -i -nobH --no-messages '.{0,80}expose_frame.{0,80}'" 0.113 | "find -name '.?*' -prune -o -type f -print | xargs rg -i -nobH --no-messages '.{0,100}expose_frame.{0,100}'" It seems that a reasonable compromise is a context of 80 characters, which is only two times slower than a string search with both GNU grep and ripgrep, and still very fast. (FTR, I also compared these performances with ack, ag and git grep. To my surprise, they are much slower: ack is about three times slower than GNU grep on a string search, ag is a bit slower than GNU grep on string searches but much much slower on regexp searches, and git grep is a bit faster than ripgrep (and GNU grep) on string searches but again much much slower on regexp searches.)