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: Fri, 21 Jul 2023 19:38:08 +0300 Message-ID: <83tttx9q4v.fsf@gnu.org> References: <87o7k6pmk3.fsf@localhost> <834jly351p.fsf@gnu.org> <87lefapkdx.fsf@localhost> <831qh230h5.fsf@gnu.org> <87wmyu8mi0.fsf@localhost> <83wmyu1l1k.fsf@gnu.org> <87fs5hemi1.fsf@gmx.de> <83edl11qzn.fsf@gnu.org> <874jlxebz5.fsf@gmx.de> <87lef9mqio.fsf@localhost> <87edl1scbw.fsf@gmx.de> <87fs5hmp6i.fsf@localhost> <87cz0lmoxy.fsf@localhost> <83v8edzb31.fsf@gnu.org> <87r0p1cta3.fsf@gmx.de> <87pm4ll7ox.fsf@localhost> <87a5vpcmc7.fsf@gmx.de> <878rb9l1f5.fsf@localhost> <87zg3pb6yt.fsf@gmx.de> <83zg3p9s39.fsf@gnu.org> <878rb944wi.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31615"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, michael.albinus@gmx.de, 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 Fri Jul 21 18:38:24 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 1qMt94-0007sk-Mx for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 21 Jul 2023 18:38:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qMt8o-0004jn-OA; Fri, 21 Jul 2023 12:38:06 -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 1qMt8l-0004Xj-5t for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2023 12:38: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 1qMt8k-0005EJ-Sj for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2023 12:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qMt8k-00076G-AT for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2023 12:38: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: Fri, 21 Jul 2023 16:38: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.168995746627265 (code B ref 64735); Fri, 21 Jul 2023 16:38:02 +0000 Original-Received: (at 64735) by debbugs.gnu.org; 21 Jul 2023 16:37:46 +0000 Original-Received: from localhost ([127.0.0.1]:34733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMt8U-00075g-9w for submit@debbugs.gnu.org; Fri, 21 Jul 2023 12:37:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMt8O-00075P-Sd for 64735@debbugs.gnu.org; Fri, 21 Jul 2023 12:37:44 -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 1qMt8H-0005CX-T7; Fri, 21 Jul 2023 12:37:33 -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=j63R0ElzseoRPxTXKoYo4/bMg1JDMiOJ44bgcz5ec6M=; b=iw4lcbWZBR8e /Me8xe4O+DxrigjpPDMvL33PIRqGY0KGIBHp60XbUT86kdLp0kBWv/GWSifUA+8dsGvQehJWHZi1q DryC8/jhshXeG6hjj8Z+z3BGjYmEcbqUh0nDREyM7IXiHhWwGnc6EQiQWwQo3UCSi7WX6KU6ZDgqW IPToDJOhNfI8y4fYBe8CR8ZRDplw+GSI+V7CSaSh+sNzpj1vWDjb5pqBrUWKGW1W1YVQZCHpM2nJm IC5zInziSA5k39Viz5ltIOyssbSVP2K1aiUQssdli1zLJLBbw2FEv/9oU5iOVV9Em9/NNUO9p0KJz 1auBYv346ntoV2z5JnmHnw==; 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 1qMt8H-00066l-6s; Fri, 21 Jul 2023 12:37:33 -0400 In-Reply-To: <878rb944wi.fsf@localhost> (message from Ihor Radchenko on Fri, 21 Jul 2023 16:15:41 +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:265744 Archived-At: > From: Ihor Radchenko > Cc: Michael Albinus , dmitry@gutov.dev, > 64735@debbugs.gnu.org, sbaugh@janestreet.com > Date: Fri, 21 Jul 2023 16:15:41 +0000 > > Eli Zaretskii writes: > > > The figures provided in this thread indicate speedups that are modest > > at best, so I'm not sure they justify measures which could cause > > problems (if that indeed could happen). > > Not that modest. Basically, it all depends on how frequently Emacs file API is > being used. If we take `find-lisp-find-files', which triggers more file > handler lookup, the difference becomes more significant: > > (benchmark-run-compiled 1 (find-lisp-find-files "/home/yantar92/.data" "")) > ;; (3.853305824 4 0.9142656910000007) > (let (file-name-handler-alist) (benchmark-run-compiled 1 (find-lisp-find-files "/home/yantar92/.data" ""))) > ;; (1.545292093 4 0.9098995830000014) The above just means that find-lisp is not a good way of emulating Find in Emacs. It is no accident that it is not used too much. > In particular, `expand-file-name' is commonly used in the wild to ensure > that a given path is full. For a single file, it may not add much > overheads, but it is so common that I believe that it would be worth it > to make even relatively small improvements in performance. The Right Way of avoiding unnecessary calls to expand-file-name is to program dedicated primitives that perform more specialized jobs, instead of calling existing primitives in some higher-level code. Then you can avoid these calls altogether once you know that the input file names are already in absolute form. IOW, if a specific job, when implemented in Lisp, is not performant enough, it means implementing it that way is not a good idea. Disabling file-name-handlers is the wrong way to solve these performance problems. > I am pretty sure that file name handlers are checked behind the scenes > by many other common operations. I'm pretty sure they aren't. But every file-related primitive calls expand-file-name (it must, by virtue of the Emacs paradigm whereby each buffer "lives" in a different directory), and that's what you see, by and large.