emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Re: tangle option to not write a file with same contents?
Date: Tue, 31 May 2022 23:07:13 +0700	[thread overview]
Message-ID: <t75efi$9pv$1@ciao.gmane.io> (raw)
In-Reply-To: <87r14bogp1.fsf@localhost>

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	other threads:[~2022-05-31 16:18 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
2022-05-31 16:07         ` Max Nikulin [this message]
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='t75efi$9pv$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \


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