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
Description: PNG image
emacs-Q-create-lockfiles-nil.png
Description: PNG image
patched-emacs-Q.png
Description: PNG image
patched-emacs-Q-create-lockfiles-nil.png
Description: PNG image
0001-Actually-do-nothing-when-create-lockfiles-is-nil.patch
Description: Text Data
--- End Message ---