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

[Ihor Radchenko <yantar92@gmail.com>]

I applied the discussed two patches onto main via 1525a5a64 and
f6f26d4ce. The suggested amendments were incorporated.

> 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 still had a hope that `org-babel-load-file' might be improved a bit by 
> using `byte-recompile-file' with 0 passed for ARG (previously I 
> incorrectly wrote FORCE). The goal is to avoid recompiling the tangled 
> .el file if it is not changed.

Can you please open a new thread on this? People who did not keep track
of this thread might not notice this suggestion.

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

> I have noticed that `org-babel-tangle-file' may create empty org file if 
> it does not exist. From my point of view it is questionable behavior.

Fixed. Now, set-file-times call is guarded by file-exists-p check.

> Finally some comments on performance numbers. Ihor, your test simulates 
> iterative debugging. Tangle results were likely in disk caches. Another 
> case may give different numbers. Consider single pass after small 
> modification of the source .org file. For comparison existing files are 
> mostly should be loaded from disk. I did not mean disabling disk caches 
> completely. After tangling it may take some time till files are actually 
> written to disk. I am unsure if during repetitive benchmarking some 
> files may be replaced in caches without writing to disk at all, likely 
> timeout for dirty cache pages is small enough.

My benchmark was for the best-case scenario for the proposed patch.

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.

The benchmark without the patch, would write to disks. If your concern
is correct and no actual disk writing happens due to disk caching, the
benchmark time provided in the commit message should be a lower bound of
the actual time. Then, we don't care. The existing benchmark already
illustrates that the patch can reduce tangle time significantly.

Best,
Ihor