emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Maxim Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]
Date: Wed, 24 Mar 2021 19:31:57 +0700	[thread overview]
Message-ID: <s3fbg3$gld$1@ciao.gmane.io> (raw)
In-Reply-To: <87czvv5gil.fsf@localhost>

On 19/03/2021 22:07, Ihor Radchenko wrote:
> Maxim Nikulin writes:
> 
>> I could not guess how to benchmark font-lock. I have tried to open file
>> (to get everything loaded), kill the buffer,
> 
> I usually just use profiler-start/open buffer/profiler-report. However,
> there is also https://github.com/Lindydancer/font-lock-profiler for more
> fine-grained benchmark. Also, you may instrument org-activate-links with
> elp.el (built-in).

I suspect I may not notice performance penalty due to some specific 
usage pattern (e.g. I rarely use links in heading titles) or due to 
absence of some customization. I have converted bracketed links to plain 
ones, so I have more than 4000 links in the test file. I expect that 
regexp affects loading of a file. As earlier, org-activate-links entry 
in profiler-report have less than 1%. I have tried elp. My measurements 
are not accurate due to I did not fix CPU regime to performance. I have 
seen times varied quite widely (several times) but often the numbers are 
the same with and without your patch. I am puzzled a bit by number of calls.

(progn
   (require 'elp)
   (setq elp-function-list (list #'org-activate-links))
   (elp-instrument-list nil)
   (dolist (i (number-sequence 1 10))
     (message "iter %d" i)
     (find-file "plain.org")
     (sit-for 3)
     (kill-buffer "plain.org")
     (sit-for 1))
   (elp-results))

Example for #+STARTUP: overview:

org-activate-links  560         0.028971085   5.173...e-05

For content number of calls is 410, without special settings (all) 120,
let me remind that it is for 10 find-file invocations. Another example

org-activate-links  410         0.1384633219  0.0003377154

I see such variations in both cases with and without the patch, but 
these numbers are negligible in my opinion.

I decided to stop experiments since I could not reproduce decrease in 
performance. Thank you for the font-lock-profiler link however.

So I have no reason to be against more complicated regexp.

>> Are changes in white spaces below actually modified lines in your patch
>> intended?
> 
> They are generated by aggressive-indent. Since org files mix indentation
> styles I keep getting those whitespace changes in my patches. Forgot to
> remove this time. Should I?

In my opinion, combining changes related to white spaces and meaningful 
modifications makes commits less clear, especially when reading email. 
However the following recommendation has certainly more weight:

https://orgmode.org/list/87zh2hosex.fsf@bzg.fr/ From: Bastien
> Also, the convention in Emacs is to avoid whitespaces-only commits,
> you need to fix whitespaces within other non-whitespaces changes in
> a commit.



  reply	other threads:[~2021-03-24 12:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-13  2:56 Ihor Radchenko
2021-03-13  3:23 ` Kyle Meyer
2021-03-13  5:21   ` [PATCH] " Ihor Radchenko
2021-03-13  5:24     ` Ihor Radchenko
2021-03-15 11:54       ` Maxim Nikulin
2021-03-16 12:35         ` Ihor Radchenko
2021-03-17 14:59           ` Maxim Nikulin
2021-03-19 15:07             ` Ihor Radchenko
2021-03-24 12:31               ` Maxim Nikulin [this message]
2021-03-24 14:11                 ` Ihor Radchenko
2021-03-19 12:10           ` Maxim Nikulin
2021-03-19 15:40             ` Ihor Radchenko
2021-03-24 12:51 ` Nicolas Goaziou
2021-03-24 13:10   ` Ihor Radchenko
2021-03-24 14:13     ` Ihor Radchenko
2021-05-15  8:34       ` Bastien

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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='s3fbg3$gld$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --subject='Re: [PATCH] Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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