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: Mon, 24 Jul 2023 14:20:50 +0300 Message-ID: <834jlttv1p.fsf@gnu.org> References: <1fd5e3ed-e1c3-5d6e-897f-1d5d55e379fa@gutov.dev> <87wmyupvlw.fsf@localhost> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17730"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, sbaugh@janestreet.com, yantar92@posteo.net, 64735@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 24 13:21:22 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 1qNtcv-0004ON-Ou for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 24 Jul 2023 13:21:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNtce-0006P9-Go; Mon, 24 Jul 2023 07:21: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 1qNtcc-0006P0-Ol for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 07:21: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 1qNtcc-0000PU-E3 for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 07:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qNtcc-00055t-9z for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 07:21: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: Mon, 24 Jul 2023 11:21: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.169019762819533 (code B ref 64735); Mon, 24 Jul 2023 11:21:02 +0000 Original-Received: (at 64735) by debbugs.gnu.org; 24 Jul 2023 11:20:28 +0000 Original-Received: from localhost ([127.0.0.1]:41902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNtc4-00054y-AL for submit@debbugs.gnu.org; Mon, 24 Jul 2023 07:20:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNtc0-00054j-MH for 64735@debbugs.gnu.org; Mon, 24 Jul 2023 07:20:26 -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 1qNtbu-0000Ew-Go; Mon, 24 Jul 2023 07:20:18 -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=FR7LxRVIVf1c4Yu40K/82nWcs2J1WHFdSaBPl4M5EMo=; b=Q++I7mtygtr1 R94QZt2UvEfTmogOVS0Wgk+rxFlo8N/OL18dTXR/pZJ5lfUu4vydgspd/+8ma471i3d2bLm5VpRAB At/fz6DW0LzHsDnKNK1qxgVM8PzbrRumQSpEvhhV0nEi9Z6j7WhCY94aPJLG6/yQWRkhj4ryUWrrn 1P2Z8XNUeVjnrTmsSGxdoTOjMCAE7A73A+3933ociQ+04t2PGslHEY6je0JIA7ywmffRwLR3q9M2+ 2RHk9ExwuvMPibxegXjsLlfpj6Np2F/QulkfTpJ1/2purjRwwdRkIjoPo6Vr24KxkoVyTYW2xGlzh OdhfcXmyph/9dHRHvF4CWQ==; 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 1qNtbj-000096-LU; Mon, 24 Jul 2023 07:20:18 -0400 In-Reply-To: <83bd4246-ac41-90ec-1df3-02d0bd59ca44@gutov.dev> (message from Dmitry Gutov on Sun, 23 Jul 2023 22:27:26 +0300) 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:265947 Archived-At: > Date: Sun, 23 Jul 2023 22:27:26 +0300 > Cc: luangruo@yahoo.com, sbaugh@janestreet.com, yantar92@posteo.net, > 64735@debbugs.gnu.org > From: Dmitry Gutov > > On 23/07/2023 20:56, Eli Zaretskii wrote: > >> And, ideally, do all the relevant benchmarking when proposing the change. > > Of course. Although the benchmarks until now already show quite a > > variability. > > Speaking of your MS Windows results that are unflattering to 'find', it > might be worth it to do a more varied comparison, to determine the > OS-specific bottleneck. > > Off the top of my head, here are some possibilities: > > 1. 'find' itself is much slower there. There is room for improvement in > the port. I think it's the filesystem, not the port (which I did myself in this case). But I'd welcome similar tests on other Windows systems with other ports of Find. Just remember to measure this particular benchmark, not just Find itself from the shell, as the times are very different (as I reported up-thread). > 2. The process output handling is worse. Not sure what that means. > 3. Something particular to the project being used for the test. I don't think I understand this one. > To look into the possibility #1, you can try running the same command in > the terminal with the output to NUL and comparing the runtime to what's > reported in the benchmark. Output to the null device is a bad idea, as (AFAIR) Find is clever enough to detect that and do nothing. I run "find | wc" instead, and already reported that it is much faster. > I actually remember, from my time on MS Windows about 10 years ago, that > some older ports of 'find' and/or 'grep' did have performance problems, > but IIRC ezwinports contained the improved versions. The ezwinports is the version I'm using here. But maybe someone came up with a better one: after all, I did my port many years ago (because the native ports available back then were abysmally slow).