[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Re: tangle option to not write a file with same contents?

From: Max Nikulin
Subject: Re: [PATCH] Re: tangle option to not write a file with same contents?
Date: Tue, 31 May 2022 23:07:13 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

On 30/05/2022 10:14, Ihor Radchenko wrote:
I applied the discussed two patches onto main via 1525a5a64 and
f6f26d4ce. The suggested amendments were incorporated.

So Greg's feature request is implemented and it is great.

I am less confident with `org-babel-load-file' though. Due to poor error handling in `org-babel-tangle' & Co., I am unsure that I can provide an example when new code incorrectly updates file modification time despite tangle failure, but I do not like that modification time is changed before attempt to tangle. Generally I expected that it is performed after tangling, perhaps with check that `org-babel-tangle-file' returned expected file name (as some hope for success).

I do not like (unless (when ...)) composition. If I remember correctly,
`when' should be used for side effects, so `and' may be more suitable
here. Otherwise it looks like what Greg suggested and should work faster
than first variant of this patch.

I did not see any documentation saying that when is for side effects.
However, or would do equivalent job there and also easier to read. So, I
changed when to or as suggested.

I have realized that the case was not exactly the same when Nicolas asked for a patch correction:

Nicolas Goaziou to emacs-orgmode. Re: [PATCH] Fix moving cursor in org-set-tags-command. Fri, 08 May 2020 09:53:55 +0200.

"Please replace `and' with `when' if side-effects are involved."

I am still curious if it is reliable to compare file size from
`file-attributes' with (+ 1 (bufferpos-to-filepos (buffer-size))) for
tangle result prior to loading existing file. I am unsure due to
variations in encodings and newline formats, however it might further
improve performance then tangle result changes.

In my testing, I did not notice any significant difference.

It is because you tangle a lot of files most of them are not changed. Otherwise it is possible to avoid loading of large enough file just because file size is different in comparison to the tangle result.

Given than
bufferpos-to-filepos can be tricky and sometimes return nil (see the
docstring on QUALITY arg), I do not think that it is worth bothering.

It seems I was wrong that buf_charpos_to_bytepos has a quick way to get byte when end of buffer is passed as the argument. So improvement of performance may be significantly less than I initially expected. Let's leave it as is.

Everything is tangled to files prior to running the benchmark. This way,
none of the tangled files should change when calling org-babel-tangle
and no disk caches should be involved.

I am trying to say that in your benchmark file are not read from disk, almost certainly they are cached in memory. Besides write cache, while reading, content may be taken from cache as well.

Actually I am just speculating, while you have benchmark result. It is unlikely that I will decide to spend some time arranging another test to convince you with numbers, priority of such activity is not high enough.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]