bug#70216: 30.0.50; self-insert-command doesn't respect create-lockfiles

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 05 Apr 2024 12:52:39 +0200
> From:  Theodor Thornhill via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 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.
> ```

I guess we need to fix the documentation, then.

> 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.

This is on purpose.  We decided that create-lockfiles = nil is meant
to disable the creation of lock files, but it is not meant to disable
userlock--ask-user-about-supersession-threat, for example, which is an
important feature we don't want to lose just because the user doesn't
want to have lock files.  See bug#53207 for some discussion of this.
Bug#49507 is also relevant.

> 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.

I don't think we want to install this patch, since we do want the
file-change detection, which is done as part of this code.

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

Lock files and file-change detection are Emacs safety measures that
are important on any modern OS.  Disabling them because they eat up
CPU cycles is wrong, from where I stand.  That said, hundreds of
milliseconds for 2 calls to 'stat' sounds excessive to me, so please
tell more details and try to show the breakdown of this long time.

> 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

There were more changes there, see above.