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#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP Date: Sat, 07 Sep 2024 09:29:18 +0300 Message-ID: <86ttesyo1t.fsf@gnu.org> References: <87o75241qh.fsf@gmail.com> <86plpi2ixa.fsf@gnu.org> <87seudke20.fsf@gmail.com> <8634md2vc2.fsf@gnu.org> <87h6asrk42.fsf@gmx.de> <86a5gk28ht.fsf@gnu.org> <87le0450x8.fsf@gmx.de> <865xr8228d.fsf@gnu.org> <87jzfofzcl.fsf@gmail.com> <8634mc1ty0.fsf@gnu.org> <87h6asl3hl.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31574"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael.albinus@gmx.de, 73046@debbugs.gnu.org To: Suhail Singh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 07 08:54:38 2024 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 1smpLC-00085L-2E for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 07 Sep 2024 08:54:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1smpKd-0001n7-MN; Sat, 07 Sep 2024 02:54:03 -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 1smpKc-0001mT-BD for bug-gnu-emacs@gnu.org; Sat, 07 Sep 2024 02:54: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 1smpKc-00027d-1u for bug-gnu-emacs@gnu.org; Sat, 07 Sep 2024 02:54:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=/jOilDbSdbarDVgAdTTEQ/gZ++b5N/3lNhxvbxg1p68=; b=NlzKF8GbjMkcBaxHwK0FWoMATogjNOgk+v6jFIR5iauNE+r0xLDdFIQBNFCIbJbcQnfa2yL4a+j0FLKq2+ck+unW2rMaUUGRO0OfmJ4FtMIEY4zYWMAZEpcXsFQ9d+dIIyU/nIrBrP80J14oXHEqBPPrCPMz+Amu4754uQUWGpSuLNZ1PHT6W002I2EfUTXzLlRKj4JI86ogaLzzUtxlblCC+uoK0jf5Am84eE0c5aIbkVy2BgfdgELO8YBzZbgaWd1Egpx6qRVPWctPMKpxTvG57BAxDgwxvIXJbs9ztGfMr8LDtjqmPNwz1hVokcJ1Wn26wpHcboRG7u+akO8a6w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1smpKc-0007Qn-F6 for bug-gnu-emacs@gnu.org; Sat, 07 Sep 2024 02:54: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: Sat, 07 Sep 2024 06:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73046 X-GNU-PR-Package: emacs Original-Received: via spool by 73046-submit@debbugs.gnu.org id=B73046.172569199828477 (code B ref 73046); Sat, 07 Sep 2024 06:54:02 +0000 Original-Received: (at 73046) by debbugs.gnu.org; 7 Sep 2024 06:53:18 +0000 Original-Received: from localhost ([127.0.0.1]:54607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smpJt-0007PA-Vt for submit@debbugs.gnu.org; Sat, 07 Sep 2024 02:53:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37370) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smpJr-0007OR-4E for 73046@debbugs.gnu.org; Sat, 07 Sep 2024 02:53:16 -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 1smowi-0007Or-8X; Sat, 07 Sep 2024 02:29:20 -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=/jOilDbSdbarDVgAdTTEQ/gZ++b5N/3lNhxvbxg1p68=; b=pr0WmCU+mbyn Cvj5NTi6NSKwGLpbaWSWkm2QEBk1E3wZjuefG7om1fvz93ltVgbzgNk7AOu0NRDleNODrdsmC0cFj SUr30kGUVzjIljGHEk/5slrqc4IOqNs9VVZzVtb+FRb9UcXMOyXKisS1gvJKeydv4fLdDLzv35DH3 CuuscipCv7Yh1tqcowyoDNpEoSOUzDQOzXxzfxI5x3N66wFVDVBgru78zcpqsZAT2SaRPccEDZA4+ UoTpxTdib46ZLSJqKiQSOf72f6NZW4TAhTNgAWXr9tskiEHX4dbchpSFKQD3BshAKJ5U9WWBZFWMP m8W49AaOVtL8ONYD8CoqxA==; In-Reply-To: <87h6asl3hl.fsf@gmail.com> (message from Suhail Singh on Fri, 06 Sep 2024 20:19:34 -0400) 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:291345 Archived-At: > From: Suhail Singh > Cc: Suhail Singh , michael.albinus@gmx.de, > 73046@debbugs.gnu.org > Date: Fri, 06 Sep 2024 20:19:34 -0400 > > Eli Zaretskii writes: > > > It needs to show around 40KB to explain 10 sec of delay. > > I don't understand your reasoning. It's simple arithmetics: if fetching a 20KB file takes 4 to 5 sec, then the 10-sec delay you reported for Dired should mean we are fetching about 40KB of data. > In fact if the output of ls -al was indeed around 40kb I would have > been very surprised. In my home directory I get: $ ls -al ~ | wc 708 6371 43324 So a large enough (but not outlandishly large: just 700 files) directory can indeed mean Emacs needs to fetch 40KB of data for refreshing a Dired buffer. Which led me to believe this is not an impossible situation. > The time taken for transferring the 20KB file included initial > connection costs whereas TRAMP would presumably be reusing the same > connection, but would be sending multiple small requests. This just makes my argument stronger: it would mean that even 40KB data moved for Dired would not quite explain the 10-sec delay. > I did some further investigation; summarizing findings below: > > A. On Host-A, the network connection is fairly slow s.t. transferring a > 20KB file takes ~5s. On Host-B, the network connection is fairly > fast. > > B. On Host-A, the time taken to refresh dired buffer containing 22 > Subdirectories (/tmp/test/src as in above code snippet) is 0.70-0.75s > with font-lock enabled, and about the same with font-lock disabled. > These times exclude the time taken to establish the intiial > connection over TRAMP. > > C. On Host-A, the time taken to refresh dired buffer containing 22 > symlinks (each symlink pointing to a directory, i.e., /tmp/test/links > in the above code snippet) is 0.70-0.75s with font-lock disabled. > With font-lock enabled the time taken is ~13-14s and the CPU is at > 100%. These times exclude the time taken to establish the intiial > connection over TRAMP. > > D. On Host-B, the time taken to display dired buffer for /tmp/test/links > with font-lock enabled is ~2s greater than when font-lock is > disabled. When /tmp/test/links contains 100 symlinks to directories > (instead of 22), the time taken when font-lock is enabled is ~6s > greater than when font-lock is disabled. > > Given above, I conclude: > > 1. The issue is present when there are symlinks to directories. > > 2. The issue is worse when there are greater number of symlinks to > directories. > > 2. The issue is worse when the connection is slower. However, it is > still observable when the connection is faster - if you're having > difficulty reproducing, increase the number of symlinks to > directories in /tmp/test/links above. > > 3. Given that when connection is slower, not only is the time taken for > font-locking greater, but the CPU is at 100%, I suspect that the > relevant code is doing some kind of busy-waiting. Thanks you. So the problem seems to be symlinks, and specifically symlinks to directories. Michael, what does Tramp do specially in these cases that could explain the slowdown? > The above observations seem consistent with Michael's comments above > regd. font-lock checks for "Broken Symbolink link" and "Symbolic link to > a directory". Michael, what do these checks entail, and why are they so CPU-expensive and take a lot of time with slow connections?