emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Re: tangle option to not write a file with same contents?
Date: Mon, 30 May 2022 11:14:02 +0800	[thread overview]
Message-ID: <87r14bogp1.fsf@localhost> (raw)
In-Reply-To: <t60fjj$s6v$1@ciao.gmane.io>

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.


  reply	other threads:[~2022-05-30  3:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28  4:04 tangle option to not write a file with same contents? Greg Minshall
2021-10-29 16:21 ` Max Nikulin
2021-10-29 17:58   ` Greg Minshall
2021-10-30 15:13     ` Max Nikulin
2021-10-30 16:13       ` Greg Minshall
2022-05-07  8:05 ` Max Nikulin
2022-05-08  4:42   ` [PATCH] " Ihor Radchenko
2022-05-17 15:39     ` Max Nikulin
2022-05-30  3:14       ` Ihor Radchenko [this message]
2022-05-31 16:07         ` Max Nikulin
2022-06-03  7:04           ` Ihor Radchenko
2022-06-07  3:47             ` Tom Gillespie
2022-06-01 13:18     ` Greg Minshall
2022-09-12 17:36       ` Org version mismatch -- hooray! Greg Minshall

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:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r14bogp1.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \


* 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


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