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: Sun, 23 Jul 2023 12:11:00 +0300 Message-ID: <831qgzuh5n.fsf@gnu.org> References: <87a5vpcmc7.fsf@gmx.de> <878rb9l1f5.fsf@localhost> <87zg3pb6yt.fsf@gmx.de> <83zg3p9s39.fsf@gnu.org> <878rb944wi.fsf@localhost> <83tttx9q4v.fsf@gnu.org> <87pm4lb4fr.fsf@gmx.de> <83pm4l9n0o.fsf@gnu.org> <87jzutb14l.fsf@gmx.de> <83mszp9kl2.fsf@gnu.org> <83h6pwa52z.fsf@gnu.org> <87ilaci637.fsf@catern.com> <83sf9g88eh.fsf@gnu.org> <87pm4krq2m.fsf@localhost> <838rb881ak.fsf@gnu.org> <87mszornlq.fsf@localhost> <83351g7yn5.fsf@gnu.org> <875y6brrnk.fsf@localhost> <83fs5f6opg.fsf@gnu.org> <87351frqr7.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40093"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, rms@gnu.org, sbaugh@catern.com, dmitry@gutov.dev, michael.albinus@gmx.de, 64735@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 23 11:11:26 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 1qNV7d-000AFV-SS for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 23 Jul 2023 11:11:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNV7I-0006E9-HZ; Sun, 23 Jul 2023 05:11:04 -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 1qNV7G-0006E0-TG for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2023 05:11:02 -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 1qNV7G-0005ZY-Ll for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2023 05:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qNV7G-00078T-H6 for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2023 05:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Jul 2023 09:11:02 +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.169010344727409 (code B ref 64735); Sun, 23 Jul 2023 09:11:02 +0000 Original-Received: (at 64735) by debbugs.gnu.org; 23 Jul 2023 09:10:47 +0000 Original-Received: from localhost ([127.0.0.1]:38188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNV71-000780-6b for submit@debbugs.gnu.org; Sun, 23 Jul 2023 05:10:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNV6z-00077o-46 for 64735@debbugs.gnu.org; Sun, 23 Jul 2023 05:10:46 -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 1qNV6s-0005X3-98; Sun, 23 Jul 2023 05:10:38 -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=XyFizPQv1TXWRTtIdqBl0CT17U4awXxv1d0aZh8do2g=; b=b46MJ6HVUqPB K26MRhoJLG8ruNDAu6ViMU9UJe48UxvsI9arFi9DsDOsnL/jV7hrxBjiJlqMH8tGQRfhPFeLUWK1Z iSbDN5zXxYCCazmkPCHzAIYXfiMSFC+HFTfvRA/zXUiKlBCpMtY2uJX1JTr+5Yb6he3Ew7HZB+LKK nVZe5M8SpHPMZ5rFZwwBbV7alaV2tbG1oAus0hxDN9tf+I31tNX2oeMVl0du57CXN8B9MVut36Vc9 Axmht3NoXylQETApefn0gCHTMXM69Ok2MC+NTepFvMtOZ40W3rLSkOij91gKxXFcNF5aK4pyYzya8 vzMQTQVWtR3C4kkJOVI3Eg==; 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 1qNV6e-0005cX-Ch; Sun, 23 Jul 2023 05:10:32 -0400 In-Reply-To: <87351frqr7.fsf@localhost> (message from Ihor Radchenko on Sun, 23 Jul 2023 08:11:56 +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:265877 Archived-At: > From: Ihor Radchenko > Cc: sbaugh@catern.com, sbaugh@janestreet.com, dmitry@gutov.dev, > michael.albinus@gmx.de, rms@gnu.org, 64735@debbugs.gnu.org > Date: Sun, 23 Jul 2023 08:11:56 +0000 > > Eli Zaretskii writes: > > >> But won't the Elisp callback always result in a queue that will > >> effectively be synchronous? > > > > I don't understand the question (what queue?), and understand even > > less what you are trying to say here. Please elaborate. > > Consider (async-directory-files-recursively dir regexp callback) with > callback being (lambda (file) (start-process "Copy" nil "cp" file "/tmp/")). What is async-directory-files-recursively, and why are we talking about it? I was talking about an implementation of directory-files-recursively as a primitive in C. That's not async code. So I don't understand why we are talking about some hypothetical async implementation. > `async-directory-files-recursively' may fire CALLBACK very frequently. > According to the other benchmarks in this thread, a file from directory > may be retrieved within 10E-6s or even less. Elisp will have to arrange > the callbacks to run immediately one after other (in a queue). > Which will not be very different compared to just running callbacks in a > synchronous loop. Regardless of my confusion above, no one said the callback must necessarily operate on each file as soon as its name was retrieved, nor even that the callback must be called for each file.