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#51523: 29.0.50; gnus-mime-view-part-externally very slow Date: Mon, 01 Nov 2021 17:00:15 +0200 Message-ID: <831r3zncow.fsf@gnu.org> References: <87v91dmcyz.fsf@gnus.org> <7b7f5641fcf9629c6074@heytings.org> <875ytcwxp7.fsf@gnus.org> <6abcac838b0dd46d94cf@heytings.org> <87sfwgvi73.fsf@gnus.org> <6abcac838bc0f53a0f78@heytings.org> <6abcac838bb83b0904d7@heytings.org> <6abcac838b7f89ee4e21@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24480"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51523@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 01 16:01:13 2021 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 1mhYoC-0006BZ-QR for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Nov 2021 16:01:13 +0100 Original-Received: from localhost ([::1]:39996 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mhYoB-0007GP-BL for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Nov 2021 11:01:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51582) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhYo3-0007FK-I9 for bug-gnu-emacs@gnu.org; Mon, 01 Nov 2021 11:01:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52543) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mhYo2-0008KD-KV for bug-gnu-emacs@gnu.org; Mon, 01 Nov 2021 11:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mhYo2-00058E-EX for bug-gnu-emacs@gnu.org; Mon, 01 Nov 2021 11:01: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, 01 Nov 2021 15:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51523 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 51523-submit@debbugs.gnu.org id=B51523.163577883919689 (code B ref 51523); Mon, 01 Nov 2021 15:01:02 +0000 Original-Received: (at 51523) by debbugs.gnu.org; 1 Nov 2021 15:00:39 +0000 Original-Received: from localhost ([127.0.0.1]:35856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mhYne-00057T-O5 for submit@debbugs.gnu.org; Mon, 01 Nov 2021 11:00:39 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mhYnb-00057E-1a for 51523@debbugs.gnu.org; Mon, 01 Nov 2021 11:00:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60138) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhYnU-0007lT-1I; Mon, 01 Nov 2021 11:00:28 -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=31HgWpIA1gac5sA2VorGcaw4Cl8VULeLmf4Pnnhew2I=; b=brls6cXCBapo +hDCvKvH/VxtL8mDyw0GdpCC5rsYw6kSpx9EYq2CXePCFNnFEkejDAYTqy+2G6e1dfJUHThrZ9znl O7op3Il7RqMqxCNMhNIjyMZih7RNqOrp/ev8JwI7citmr9MmQB8356malA1wZfD3vfLC8C0pN2ciu 8FayItuK8nc1kIhmc2Ql076tN/vQNOscvEd+f/J1VSV3fYgi9DPQ8+vh43yzm2xcObOiic4La5Klx BkKrg/qwYlLYa6xxLaZehIcZ6owTUuUoAICThJlj8wL+QmcqaKv7ucMV4xfxCEJwf+yuv2mNK2Hm6 LK1geUEU4JOLEPdq8hNyQA==; Original-Received: from [87.69.77.57] (port=4745 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 1mhYnP-0002N9-B7; Mon, 01 Nov 2021 11:00:27 -0400 In-Reply-To: <6abcac838b7f89ee4e21@heytings.org> (message from Gregory Heytings on Mon, 01 Nov 2021 12:26:03 +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" Xref: news.gmane.io gmane.emacs.bugs:218766 Archived-At: > Date: Mon, 01 Nov 2021 12:26:03 +0000 > From: Gregory Heytings > Cc: 51523@debbugs.gnu.org, Stefan Monnier > > I attach a better patch, it uses a file-has-change-p function instead of a > when-file-has-changed macro. Thanks. > +(defun file-has-changed-p (file) > + "Return non-nil if FILE has changed. > +The modification time of FILE is compared to the modification > +time of FILE during a previous invocation of `file-has-changed-p'. > +Therefore the first invocation of `file-has-changed-p' always > +returns non-nil." > + (let* ((attr (file-attributes file 'integer)) > + (mtime (file-attribute-modification-time attr)) > + (saved-mtime (gethash (intern file) > + file-has-changed-p--hash-table))) > + (when (not (equal mtime saved-mtime)) > + (puthash (intern file) mtime file-has-changed-p--hash-table)))) Bother: I think this implementation might cause both false positives and false negatives. . it uses the literal file name without even expanding it to an absolute file name, so the same FILE might mean different files if default-directory changes . file names are generally not reliable enough for unique identifiers of files (think symlinks on all systems, letter-case and numerical tails on Windows, etc.), so we should at least use file-truename . interning the file names could produce many unnecessary symbols in the global obarray Can we make the implementation more robust by fixing these? The name of the function also doesn't reflect what it does: it only looks at the file's last modification time, so maybe at least "time" should be in the name? I also question the decision of testing modification time for equality: why not check if the time stamp is newer, and disregard the changes to an older time stamp? When looking this way at this function, I ask myself whether extending file-newer-than-file-p to do this job would be a better idea? Or maybe I don't understand the general use case for this function.