GNU bug report logs - #69444
30.0.50; 5 seconds to save file

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 69444 in the body.
You can then email your comments to 69444 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Deric Bytes <dericbytes <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; 5 seconds to save file
Date: Wed, 28 Feb 2024 00:32:10 +0000

[Message part 1 (text/plain, inline)]

Saving a small file in emacs -q seems to take 1  to 5 seconds.

I assume this because the 'Rapid Refresh' app I am using takes 1 to 5
seconds to notice
the file change when I change it with emacs but 0 seconds when changed with
another editor.
.
I have done a recent and fresh install of emacs to see if it fixed it but
had no luck.

# set up rapid refresh app
npx create-expo-app <at> latest -t tabs <at> 50
cd my-app
npx expo start
w
http://localhost:8082/

emacs -q 'app/(tabs)/index.tsx'
;; added a letter to a welcome string.
M-x save-buffer

Expected result:  the 'Fast Refresh' of expo should instantly update
the web page.

Actual result: a variable 1 to 6 second delay (repeating same process)
before update

Actual result with neovim: page save leads to instant update every time.

I tried disabling these with no effect on the time

 (setq before-save-hook nil)
 (setq after-save-hook nil)
 (setq vc-handled-backends nil)

I profiled save-buffer and it was
'0 0% ...'



In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.37, cairo version 1.16.0) of 2023-05-13 built on no-control-x1c
Repository revision: 7791907c3852e6ec197352e1c3d3dd8487cc04f5
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12302000
System Description: Ubuntu 23.10

Configured using:
 'configure --with-tree-sitter --with-mailutils --with-json
 --with-xwidgets --with-modules --with-imagemagick
 --prefix=/home/no-control/installs --bindir=/home/no-control/bin
 --with-native-compilation=no --with-xft'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ IMAGEMAGICK
JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM XWIDGETS
GTK3 ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils extra-functions
thingatpt help-fns radix-tree cl-print byte-opt gv bytecomp byte-compile
debug backtrace help-mode find-func profiler time-date subr-x
cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 55658 12506)
 (symbols 48 6603 0)
 (strings 32 18066 1619)
 (string-bytes 1 523080)
 (vectors 16 52241)
 (vector-slots 8 1066424 14413)
 (floats 8 38 50)
 (intervals 56 663 0)
 (buffers 984 18))

[Message part 2 (text/html, inline)]

Message #8 received at 69444 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Deric Bytes <dericbytes <at> gmail.com>
Cc: 69444 <at> debbugs.gnu.org
Subject: Re: bug#69444: 30.0.50; 5 seconds to save file
Date: Wed, 28 Feb 2024 14:03:56 +0200

> From: Deric Bytes <dericbytes <at> gmail.com>
> Date: Wed, 28 Feb 2024 00:32:10 +0000
> 
> Saving a small file in emacs -q seems to take 1  to 5 seconds.

I sincerely doubt that, see below.  Especially if the file's contents
is plain ASCII, so doesn't need any encoding when saving it.

> I assume this because the 'Rapid Refresh' app I am using takes 1 to 5 seconds to notice 
> the file change when I change it with emacs but 0 seconds when changed with another editor.

You will need to tell us how does Rapid Refresh detect such changes,
because I don't know that.  I also don't know what do "other editors"
do when you save a modified file.  I do know what Emacs does by
default: it renames the original file to the backup file name (so a
file FOO will be renamed to FOO~), and then writes a _new_ file under
the original-file name with the new contents.  So from the filesystem
POV, what happens is that the original file is renamed to a different
name, and then a new file appears under the name of the original file.
The question is: how would Rapid Refresh detect such changes, and what
would be the time frame for that?

If "other editors" overwrite the original file with new contents, the
filesystem could have a very different view of what happens, and thus
the detection by Rapid Refresh could exhibit different timings.

Message #11 received at 69444 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Deric Bytes <dericbytes <at> gmail.com>
Cc: 69444 <at> debbugs.gnu.org
Subject: Re: bug#69444: 30.0.50; 5 seconds to save file
Date: Wed, 28 Feb 2024 17:49:37 +0200

tags 69444 notabug
close 69444
thanks

[Please use Reply All to reply, to keep the bug tracker on the CC list.]

> From: Deric Bytes <dericbytes <at> gmail.com>
> Date: Wed, 28 Feb 2024 14:37:16 +0000
> 
> SOLVED: It works instantaneously turning of create-lockfiles 
> 
> (setq create-lockfiles nil)

So you need to investigate why deleting a lock file either slows down
Emacs or slows down the Rapid Refresh's recognition of the fact that
the file was updated.

In any case, this doesn't seem to be a bug in Emacs, so I'm closing
it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.