From: Max Nikulin <manikulin@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>, Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Time resolution in Emacs
Date: Mon, 25 Apr 2022 23:54:58 +0700 [thread overview]
Message-ID: <7ae621ed-d03b-00cd-bfb3-04a4a2a7d5ce@gmail.com> (raw)
In-Reply-To: <3008dea1-572b-9010-f3c4-15272145fd8a@cs.ucla.edu>
On 25/04/2022 22:34, Paul Eggert wrote:
> On 4/22/22 23:51, Eli Zaretskii wrote:
>
>>> There are Gnulib library functions to
>>> deal with this sort of thing; it's not a new problem.
>>
>> Doesn't that slow down applications?
>
> Not significantly, no. file-attributes already has the file's filesystem
> ID and timestamps so Emacs can easily cache that (it's a small cache
> with only one entry per filesystem). There's no need to traipse through
> the filesystem looking at other files. This is what coreutils does and
> it works well in practice. It's not expensive and not that complicated.
>
> Your suggestion of maintaining a static table for known filesystem types
> is a good one; we could do that to improve common cases. I would like to
> take a look into doing this.
Notice that on Linux while file metadata are in cache, timestamps may
have high time resolution. When later fetched from disk they may have
coarse resolution, e.g. whole seconds.
Generally it is fragile to rely on file modification time. That is why
build systems relying of file hashes appeared.
As to 16ms resolution, at least for `benchmark-run' I would like to have
finer granularity.
On the other hand, when higher timer frequency is required, from my
point of view, it may be better to run such application in a separate
process.
next prev parent reply other threads:[~2022-04-25 16:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com>
[not found] ` <149de00f-115b-5367-414f-c7700ef8966b@cs.ucla.edu>
[not found] ` <c6525aa8-1496-8ebe-cf2a-24f65cc44672@gmail.com>
[not found] ` <2dd15844-01b3-0144-740c-185ec8488a81@cs.ucla.edu>
[not found] ` <4a23f3a4-fe8f-d396-49d8-10034803be63@gmail.com>
[not found] ` <52fb10fb-892a-f273-3be8-28793f27e204@cs.ucla.edu>
[not found] ` <5cd820d4-ae67-43d4-9e63-c284d51ff1e4@gmail.com>
[not found] ` <f9d9d26c-1974-b52a-8f4d-49167676c102@cs.ucla.edu>
[not found] ` <83tuapvcxs.fsf@gnu.org>
[not found] ` <6efc5d24-34a2-fd30-cd20-fe4ac3e48310@cs.ucla.edu>
[not found] ` <83fsm8tdzl.fsf@gnu.org>
[not found] ` <9e4781b2-2ffa-b1ce-09b4-ead82cad9038@cs.ucla.edu>
[not found] ` <83ilr3siku.fsf@gnu.org>
[not found] ` <4e41671c-fae8-61c4-845c-4c7ba4317e88@cs.ucla.edu>
[not found] ` <83fsm7sh2s.fsf@gnu.org>
[not found] ` <e4cc58ca-51f9-395e-05f5-5f06cb9d439d@cs.ucla.edu>
[not found] ` <83czhbsgc2.fsf@gnu.org>
[not found] ` <33fb24fb-282b-cc13-a597-e7b63f19982d@cs.ucla.edu>
[not found] ` <83y1zzq6kd.fsf@gnu.org>
[not found] ` <aa2bc0a0-1bec-37ff-919d-c20fcdfdab68@cs.ucla.edu>
2022-04-22 5:23 ` Time resolution in Emacs argument optional ones Eli Zaretskii
2022-04-22 18:22 ` Paul Eggert
2022-04-22 18:52 ` Corwin Brust
2022-04-22 21:26 ` Paul Eggert
2022-04-23 6:27 ` Time resolution in Emacs Eli Zaretskii
2022-04-24 0:56 ` Paul Eggert
2022-04-24 6:10 ` Eli Zaretskii
2022-04-24 11:47 ` Max Nikulin
2022-04-24 12:23 ` Eli Zaretskii
2022-04-25 15:32 ` Paul Eggert
2022-04-25 16:01 ` Eli Zaretskii
2022-04-22 19:35 ` Time resolution in Emacs argument optional ones Eli Zaretskii
2022-04-22 21:52 ` Paul Eggert
2022-04-23 6:51 ` Time resolution in Emacs Eli Zaretskii
2022-04-25 15:34 ` Paul Eggert
2022-04-25 16:10 ` Eli Zaretskii
2022-04-25 16:38 ` Paul Eggert
2022-04-25 16:57 ` Eli Zaretskii
2022-04-25 16:54 ` Max Nikulin [this message]
2022-04-25 17:02 ` Eli Zaretskii
2022-04-25 19:27 ` Paul Eggert
2022-04-29 15:19 ` Max Nikulin
2022-04-29 16:07 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7ae621ed-d03b-00cd-bfb3-04a4a2a7d5ce@gmail.com \
--to=manikulin@gmail.com \
--cc=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).