From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#26710: Fwd: 25.2; project-find-regexp makes emacs use 100% cpu Date: Tue, 2 May 2017 13:00:06 +0300 Message-ID: <9474c678-b092-81f0-f5b3-f26d4467ac86@yandex.ru> 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> <83inlljb5r.fsf@gnu.org> <83lgqfivb0.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1493719278 17490 195.159.176.226 (2 May 2017 10:01:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 2 May 2017 10:01:18 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Thunderbird/53.0 Cc: hariharanrangasamy@gmail.com, 26710@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 02 12:01:14 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 1d5UcK-0004QW-Bp for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 May 2017 12:01:12 +0200 Original-Received: from localhost ([::1]:57784 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5UcQ-0004v8-39 for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 May 2017 06:01:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5UcF-0004ty-PO for bug-gnu-emacs@gnu.org; Tue, 02 May 2017 06:01:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5UcA-000490-Tk for bug-gnu-emacs@gnu.org; Tue, 02 May 2017 06:01:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52138) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d5UcA-00048l-QC for bug-gnu-emacs@gnu.org; Tue, 02 May 2017 06:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1d5UcA-00023I-9u for bug-gnu-emacs@gnu.org; Tue, 02 May 2017 06:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 May 2017 10:01:02 +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.14937192197825 (code B ref 26710); Tue, 02 May 2017 10:01:02 +0000 Original-Received: (at 26710) by debbugs.gnu.org; 2 May 2017 10:00:19 +0000 Original-Received: from localhost ([127.0.0.1]:50337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d5UbS-000229-LV for submit@debbugs.gnu.org; Tue, 02 May 2017 06:00:18 -0400 Original-Received: from mail-wm0-f50.google.com ([74.125.82.50]:38211) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d5UbP-00021u-5p for 26710@debbugs.gnu.org; Tue, 02 May 2017 06:00:16 -0400 Original-Received: by mail-wm0-f50.google.com with SMTP id r190so13211895wme.1 for <26710@debbugs.gnu.org>; Tue, 02 May 2017 03:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=g0DYidR6e5Hn4EJ+tVKGYAUL5J1PZEUs9T0O8S4tjTo=; b=ieZRlNVRP7P4S56c/Mk3ObhMsnuZlBPTLcZ3a2uKINELrgljgJXeY9oD/l6+7CYCTE B+TFnrk5fDTYONc4wiq5ysrL47Sj/R7iJ7tLK7rnQFQ1lilVtYD7L50vEJZIvPH3/2Ku 7xKIpf09rtDOwJfRG/s/2lkzC+ZIT9pyZe4vRoKj9vrd+xy/7Db6BBKQMeoqrZBHZTpV a+dGdEYFXgPqTK6GyCbexRYi0tcs9Y9cHOYbuzYMZjGF6g10XcJsbVKx+ZcV/Qa3nPL2 Xl0TgR94/e7+gpkiCnGwX4sSj/LbWer7fQVTjwiya8eueCjYGfGAVMkIiC1XWpqBKwb+ uTZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=g0DYidR6e5Hn4EJ+tVKGYAUL5J1PZEUs9T0O8S4tjTo=; b=EikTFxjoljC/60fPBS//m8staGGhSuX7n2QZUoA2dQV+ERJompuYkFWRxHiiGzxgBs Bk8IJ8zTOKTgVNL9rzzvOSi+Nktl4erbjr1px7VYcyYO9n2smH6ytBFRXpPq3UdCWMXS rY+W+tKHg8Y2sr0ZE2TGZCMrm3SA7pU4S5u0YkBKZ3BJG57/1h+FEIYV0Ioj6ZSNLJB6 4LCzJrxk4OFVLe8vSAkp6ZOr5Sj3Xt6T7lLK2lD7oPdLwHtTToGzon0FxGRGiYQq55Hz QmhhVPMiQQCTdxkM8lSD2vAkF66e7pgYMtcUMszzw5QIz2l6XvXpe3ktIPF79iI2dtfZ 2DgA== X-Gm-Message-State: AN3rC/4gALTRgSaK8f4JVxXXpZZmJKIhrmOj//bEaUUTzjqNnl2Gbed8 B5ciIj+TYvUgSw== X-Received: by 10.28.0.201 with SMTP id 192mr1613001wma.126.1493719209376; Tue, 02 May 2017 03:00:09 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.173.156]) by smtp.googlemail.com with ESMTPSA id l82sm378164wmf.17.2017.05.02.03.00.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 03:00:08 -0700 (PDT) In-Reply-To: <83lgqfivb0.fsf@gnu.org> Content-Language: en-US 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:132185 Archived-At: On 02.05.2017 10:15, Eli Zaretskii wrote: > Can you explain the significance of xref--regexp-syntax-dependent-p's > tests? I don't know enough about xref to grasp that just by looking > at the changes. When it returns nil (the regexp is not affected by syntax-table): If the file containing the hit is not open, we now skip inserting the first few lines of that file into the temporary buffer, and calling set-auto-mode. And, whether it's open or not, we skip the syntax-propertize call. >> With this, project-find-regexp for 'emacs' finally completes in ~10 >> seconds on my machine. > > It takes about 15 here (and 45 in an unoptimized build). I guess this > slowdown is expected, since this is a 32-bit build --with-wide-int, so > should be 30% slower than with native ints. Thanks for testing. To be more accurate, it's about 10 seconds in my normal session, and about 6 seconds starting with 'emacs -Q'. My laptop is most likely faster. > If the processing is in filter and sentinel functions, I'm not sure we > will need any further speedups, because the UI will remain responsive. The filter and sentinel functions are not allowed to have direct access to the final output buffer, hence the need for abstraction. I guess you favor the "one callback per hit" approach, then. Still, if the filter function and sentinel functions take a lot of time (and/or get called a lot), like it will be in this example, the UI can't as responsive as usual, can it? >>> 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. >> >> I imagined that the xref API that allows this kind of asynchronous >> results might look better and more readable if it's implemented with >> threads underneath. > > If you need advice for how to implement something like that, I can try > helping with threads. I'd like a more general advice first. E.g. do we want to go this road? The dir-status-files like scheme should work without threads, too. It seems a bit brittle, though: if the process filter is supposed to be calling the callback for each item, the callback has to be in place right away. And the process will be started before that happens. We'll probably be saved by filters having to wait until the current command finishes executing, though. >> The main thing to understand is the xref API, not the internals of the >> package. > > Well, I lack that understanding as well. I'm hoping it's not too hard to obtain even just by reading the Commentary section in xref.el. But hey, you don't have to. The callbacks approach seems viable, too.