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

[Max Nikulin]

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.
https://list.orgmode.org/87ftca6ewc.fsf@nicolasgoaziou.fr

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