GNU bug report logs - #70216
30.0.50; self-insert-command doesn't respect create-lockfiles

Previous Next

Package: emacs;

Reported by: Theodor Thornhill <theo <at> thornhill.no>

Date: Fri, 5 Apr 2024 10:54:01 UTC

Severity: normal

Found in version 30.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Theodor Thornhill <theo <at> thornhill.no>
To: 70216 <at> debbugs.gnu.org
Subject: bug#70216: 30.0.50; self-insert-command doesn't respect create-lockfiles
Date: Fri, 05 Apr 2024 12:52:39 +0200
[Message part 1 (text/plain, inline)]
Hi all!

I'm digging more and more into the internals of Emacs these days, and
while tracing input lag performance i noticed that we don't respect the
create-lockfiles option, at least not fully.

The documentation states:
```
If the option `create-lockfiles' is nil, this does nothing.
```
However, the nothing is postponed until later, inside the lock_file
function. This means we won't cretae the lockfile, but we will get the
truename-buffer, verify visited file, etc, on my system amounting to
some time spent which I thought I opted out of.

Along with a patch that fixes this behavior I've added 4 screenshots of
graphs taken through intel_pt tracing on trigger of self-insert inside a
c file.

to reproduce what I do, from inside my emacs source code folder:

```
;; normal emacs built from source a couple of days ago
emacs -Q +644 src/filelock.c
emacs -Q -eval "(setq create-lockfiles nil)" +644 src/filelock.c

;; emacs with the provided patch
./src/emacs -Q +644 src/filelock.c
./src/emacs -Q -eval "(setq create-lockfiles nil)" +644 src/filelock.c
```

The first two screenshots show the current behavior without this patch,
where you can see that we still do some lock-file related computing even
though the setting is off. The last two show that we don't do it at all,
while preserving the vanilla operation when create-lockfiles = t.

The lock file related code can take up to a millisecond on my system,
but is usually in the range of 200-300 microseconds.

It seems there was some cleanup/changes around this behavior which i
believe caused this as a regression, from around 3 years ago. I _think_
this commit: 9ce6541ac9710933beca7f9944087fe4849d5ae9

Theo

[emacs-Q.png (image/png, attachment)]
[emacs-Q-create-lockfiles-nil.png (image/png, attachment)]
[patched-emacs-Q.png (image/png, attachment)]
[patched-emacs-Q-create-lockfiles-nil.png (image/png, attachment)]
[0001-Actually-do-nothing-when-create-lockfiles-is-nil.patch (text/x-diff, attachment)]

This bug report was last modified 1 year and 103 days ago.

Previous Next


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