From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#26710: Fwd: 25.2; project-find-regexp makes emacs use 100% cpu Date: Mon, 01 May 2017 10:20:32 +0300 Message-ID: <83inlljb5r.fsf@gnu.org> References: <87a86zu3gf.fsf@hari-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83vapnktcn.fsf@gnu.org> <3d76a3ac-32ad-412d-349d-5904fc964a2b@yandex.ru> <83ziexka0s.fsf@gnu.org> <77b3a404-adac-fd1c-bd99-ad10e2450338@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1493623331 14997 195.159.176.226 (1 May 2017 07:22:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 1 May 2017 07:22:11 +0000 (UTC) Cc: hariharanrangasamy@gmail.com, 26710@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 01 09:22:07 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d55eo-0003ms-TL for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 May 2017 09:22:07 +0200 Original-Received: from localhost ([::1]:47150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d55eu-0008Gg-Eg for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 May 2017 03:22:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d55eo-0008GP-RA for bug-gnu-emacs@gnu.org; Mon, 01 May 2017 03:22:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d55ek-0006Tg-4i for bug-gnu-emacs@gnu.org; Mon, 01 May 2017 03:22:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50254) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d55ek-0006TY-2W for bug-gnu-emacs@gnu.org; Mon, 01 May 2017 03:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1d55ej-0002Pw-Rb for bug-gnu-emacs@gnu.org; Mon, 01 May 2017 03:22: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: Mon, 01 May 2017 07:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26710 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26710-submit@debbugs.gnu.org id=B26710.14936232719232 (code B ref 26710); Mon, 01 May 2017 07:22:01 +0000 Original-Received: (at 26710) by debbugs.gnu.org; 1 May 2017 07:21:11 +0000 Original-Received: from localhost ([127.0.0.1]:48453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d55du-0002Oq-Of for submit@debbugs.gnu.org; Mon, 01 May 2017 03:21:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d55dt-0002Oe-Bm for 26710@debbugs.gnu.org; Mon, 01 May 2017 03:21:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d55dj-0005p2-G3 for 26710@debbugs.gnu.org; Mon, 01 May 2017 03:21:04 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d55dj-0005or-Cc; Mon, 01 May 2017 03:20:59 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3077 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1d55di-0005RA-8O; Mon, 01 May 2017 03:20:58 -0400 In-reply-to: <77b3a404-adac-fd1c-bd99-ad10e2450338@yandex.ru> (message from Dmitry Gutov on Mon, 1 May 2017 05:42:21 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:132153 Archived-At: > Cc: hariharanrangasamy@gmail.com, control@debbugs.gnu.org, > 26710@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 1 May 2017 05:42:21 +0300 > > On 30.04.2017 21:47, Eli Zaretskii wrote: > > > I'll try to look at this. According to my profiling, the lion's share > > of time is taken by xref--collect-matches, so that's the place to try > > concurrency. > > I think that's too late. By the time xref--collect-matches is called > (and it's called for each hit), we've already spent time synchronously > waiting for the find-grep invocation to finish. In my testing, find-grep finishes almost instantaneously. The exception is when you have a cold cache, but even then it takes about 10% of the total run time, for the Emacs source tree (which yields about 100,000 hits in the test case). > When there are a lot of matches, xref--collect-matches can take some > significant time, with opening the buffers and everything. That can be > optimized, however, as a separate issue, and I don't think there's > anything to parallelize there, since it all happens in Elisp. I thought the request was to allow the user do something in the foreground, while this processing runs in the background. If that's not what was requested, then I guess I no longer understand the request. > What we _can_ manage to run in parallel, in the find-grep process in the > background, and the post-processing of the results in Elisp. Yes, you can -- if you invoke find-grep asynchronously and move the processing of the hits to the filter function. But that doesn't need to involve threads, and is being done in many packages/features out there, so I'm not sure what did you ask me to do with this. IOW, it should be "trivial", at least in principle, to make this command work in the background, just like, say, "M-x grep". > Here's how I imagine it: I'm not sure I understand the need for this complexity, given that async subprocesses are available. I'm probably missing something because I know too little about the internals of the involved code.