From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#64735: 29.0.92; find invocations are ~15x slower because of ignores Date: Thu, 27 Jul 2023 11:47:55 +0300 Message-ID: <83edktn3k4.fsf@gnu.org> References: <5c4d9bea-3eb9-b262-138a-4ea0cb203436@gutov.dev> <87tttypp2e.fsf@localhost> <87r0p030w0.fsf@yahoo.com> <83sf9f6wm0.fsf@gnu.org> <83sf9eub9d.fsf@gnu.org> <2d844a34-857d-3d59-b897-73372baac480@gutov.dev> <83bkg2tsu6.fsf@gnu.org> <83bd4246-ac41-90ec-1df3-02d0bd59ca44@gutov.dev> <834jlttv1p.fsf@gnu.org> <937c3b8e-7742-91b7-c2cf-4cadd0782f0c@gutov.dev> <83a5vlsanw.fsf@gnu.org> <69a98e2a-5816-d36b-9d04-8609291333cd@gutov.dev> <87351cs8no.fsf@localhost> <35163e56-607d-9c5b-e3e8-5d5b548b3cb7@gutov.dev> <878rb3m43b.fsf@localhost> <83v8e6lyi4.fsf@gnu.org> <87lef17ok8.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22777"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, dmitry@gutov.dev, 64735@debbugs.gnu.org, sbaugh@janestreet.com To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 27 11:06:49 2023 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 1qOwxM-0005f7-AU for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 27 Jul 2023 11:06:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qOwfF-00081z-5f; Thu, 27 Jul 2023 04:48:05 -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 1qOwfD-00081o-4C for bug-gnu-emacs@gnu.org; Thu, 27 Jul 2023 04:48:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qOwfC-0006BS-66 for bug-gnu-emacs@gnu.org; Thu, 27 Jul 2023 04:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qOwfB-00027G-RM for bug-gnu-emacs@gnu.org; Thu, 27 Jul 2023 04:48: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: Thu, 27 Jul 2023 08:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64735 X-GNU-PR-Package: emacs Original-Received: via spool by 64735-submit@debbugs.gnu.org id=B64735.16904476367938 (code B ref 64735); Thu, 27 Jul 2023 08:48:01 +0000 Original-Received: (at 64735) by debbugs.gnu.org; 27 Jul 2023 08:47:16 +0000 Original-Received: from localhost ([127.0.0.1]:40717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOweR-00023y-UJ for submit@debbugs.gnu.org; Thu, 27 Jul 2023 04:47:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOweP-00023i-6p for 64735@debbugs.gnu.org; Thu, 27 Jul 2023 04:47:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qOweJ-00064Z-8j; Thu, 27 Jul 2023 04:47:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FGidqSqyf3NQoMOuBTjJkJ1H2ZvLfT/qCzbWv9CTy9g=; b=YHi74+EpbofA X/ZZe1fH7BGp53f0FOFpoRkl1tv0noSjQJgUJBM12id2RJTzt3o0sQ2K5NiCV1Dgc8JHjlEttxaAv vbFXteHQSMNpAkT1aVSXl+m0tPKpqfi9hyeNu8JuqADRyV6ABCZYoC8cj/WE3mk2ueneSFZ+EFKr/ UBTltMmkv/dSTT+HiUBy9jjdaQE9EgvsgnmmMIK4amkQwq1x7No7492ZwEa1lLej4F6KNbQ53QGY2 stXuFPGRbKYyo/o1Z5GKXOuGBlcmtLDeev6r0eZXLNesDL6hY1fyJmquXlpB55xKr58kPAFS9ole/ +pefz/1jjGzPITJkFBZIxQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qOweI-0004Zi-OT; Thu, 27 Jul 2023 04:47:07 -0400 In-Reply-To: <87lef17ok8.fsf@localhost> (message from Ihor Radchenko on Thu, 27 Jul 2023 08:20:55 +0000) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:266174 Archived-At: > From: Ihor Radchenko > Cc: Dmitry Gutov , luangruo@yahoo.com, > sbaugh@janestreet.com, 64735@debbugs.gnu.org > Date: Thu, 27 Jul 2023 08:20:55 +0000 > > Eli Zaretskii writes: > > >> Skipping regexp matching entirely, though, will make this benchmark > >> farther removed from real-life usage: this thread started from being > >> able to handle multiple ignore entries when listing files (e.g. in a > >> project). > > > > Agreed. From my POV, that variant's purpose was only to show how much > > time is spent in matching file names against some include or exclude > > list. > > Yes and no. > > It is not uncommon to query _all_ the files in directory and something > as simple as > > (when (and (not (member regexp '("" ".*"))) (string-match regexp file))...) > > can give considerable speedup. I don't understand what you are saying. The current code already checks PREDICATE for being nil, and if it is, does nothing about filtering. And if this is about testing REGEXP for being a trivial one, adding such a test to the existing code is trivial, and hardly justifies an objection to what I wrote. > > There's a possibility of pushing this filtering into > > file-name-all-completions, but I'm not sure that will be faster. We > > should try that and measure the results, I think. > > Isn't `file-name-all-completions' more limited and cannot accept > arbitrary regexp? No, see completion-regexp-list.