* Is it possible to optimize Org Mode org-activate-links ?
@ 2021-02-13 1:10 Christopher Miles
2021-02-13 3:33 ` Ihor Radchenko
0 siblings, 1 reply; 4+ messages in thread
From: Christopher Miles @ 2021-02-13 1:10 UTC (permalink / raw)
To: Org Mode
[-- Attachment #1.1: Type: text/plain, Size: 9275 bytes --]
<#secure method=pgpmime mode=sign>
I did an profiler (with my extension "org-link-beautify").
Here is the result of (Memory and CPU).
I checked org-element-context source code, it's not so long and complex. Why it caused so many items in Memory profiler result? Is it possible to optimize it?
Here is the Emacs profiler (CPU) result:
8 2% - org-activate-links
8 2% - catch
8 2% - while
6 2% - let*
6 2% - if
6 2% - progn
6 2% - let*
5 1% - let
5 1% - if
5 1% - progn
5 1% - funcall
5 1% - org-link-beautify-display
2 0% - org-link-beautify--return-icon
2 0% org-link-beautify--warning
2 0% file-name-extension
1 0% - org-link-beautify--preview-pdf
1 0% - org-link-beautify--display-thumbnail
1 0% - create-image
1 0% - apply
1 0% - #<compiled 0x4c76891e673d173>
1 0% - image-type
1 0% - image-type-from-file-header
1 0% generate-new-buffer
1 0% - let*
1 0% - cond
1 0% - or
1 0% facep
Here is the Emacs profiler (Memory) result:
1,939,896 11% - org-activate-links
1,939,896 11% - catch
1,939,896 11% - while
1,761,816 10% - let*
1,761,816 10% - if
1,697,400 9% - progn
1,658,488 9% - let*
1,511,048 8% - let
1,511,048 8% - if
1,511,048 8% - progn
1,511,048 8% - funcall
1,511,048 8% - org-link-beautify-display
947,000 5% - org-link-beautify--get-element
947,000 5% - org-element-context
947,000 5% - catch
947,000 5% - save-excursion
947,000 5% - save-restriction
947,000 5% - let*
792,384 4% - let
792,384 4% - catch
792,384 4% - while
792,384 4% - let
792,384 4% - org-element--object-lex
792,384 4% - if
792,384 4% - let*
792,384 4% - save-excursion
792,384 4% - while
661,368 3% - let
655,272 3% - setq
655,272 3% - cond
655,272 3% - let*
655,272 3% - cond
610,224 3% - let*
610,224 3% - cond
610,224 3% - if
610,224 3% - progn
610,224 3% - org-element-link-parser
610,224 3% - catch
610,224 3% - let
450,480 2% - cond
225,240 1% - setq
225,240 1% - org-link-expand-abbrev
139,248 0% - org-link-unescape
131,064 0% - replace-regexp-in-string
8,184 0% apply
85,992 0% - if
77,808 0% not
8,184 0% - let*
8,184 0% and
163,800 0% - cond
61,440 0% or
8,184 0% setq
159,744 0% - if
98,304 0% - progn
49,152 0% if
49,152 0% - setq
49,152 0% replace-regexp-in-string
45,048 0% - and
45,048 0% - org-element-link-parser
45,048 0% - catch
45,048 0% - let
32,760 0% cond
12,288 0% if
131,016 0% and
154,616 0% - or
154,616 0% - org-element-at-point
154,616 0% - save-excursion
154,616 0% - save-restriction
154,616 0% - let
154,616 0% - cond
79,864 0% - progn
79,864 0% - let*
71,680 0% - org-at-heading-p
71,680 0% outline-on-heading-p
74,752 0% - org-element--parse-to
74,752 0% - catch
74,752 0% - save-excursion
74,752 0% - save-restriction
74,752 0% - let*
74,752 0% - cond
74,752 0% - if
74,752 0% - progn
74,752 0% - let*
74,752 0% outline-previous-heading
368,568 2% - file-name-extension
36,864 0% file-name-sans-versions
133,272 0% - org-link-beautify--preview-pdf
109,788 0% - org-link-beautify--display-thumbnail
107,898 0% - create-image
107,898 0% - apply
107,898 0% - #<compiled 0x4c76891e673d173>
107,898 0% - image-type
107,898 0% - image-type-from-file-header
63,048 0% insert-file-contents-literally
32,760 0% image-type-from-buffer
126 0% generate-new-buffer
22,512 0% - org-link-unescape
22,512 0% - replace-regexp-in-string
16,368 0% apply
22,352 0% org-link-beautify--display-icon
9,216 0% - org-link-beautify--return-icon
8,184 0% org-link-beautify--warning
139,256 0% - save-excursion
139,256 0% - let
139,256 0% - unwind-protect
139,256 0% - progn
139,256 0% - org-element-link-parser
139,256 0% - catch
139,256 0% - let
103,416 0% - cond
50,168 0% - setq
50,168 0% - org-link-expand-abbrev
34,808 0% - org-link-unescape
26,624 0% replace-regexp-in-string
15,360 0% - if
15,360 0% not
30,720 0% - cond
15,360 0% or
35,840 0% - if
18,432 0% - progn
9,216 0% if
9,216 0% - setq
9,216 0% replace-regexp-in-string
8,184 0% - list
8,184 0% - let*
8,184 0% if
38,912 0% - let
38,912 0% + let*
64,416 0% + and
[-- Attachment #1.2: Type: text/html, Size: 11724 bytes --]
[-- Attachment #2: ATT00001.txt --]
[-- Type: text/plain, Size: 253 bytes --]
--
[ stardiviner ]
I try to make every word tell the meaning that I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Is it possible to optimize Org Mode org-activate-links ?
2021-02-13 1:10 Is it possible to optimize Org Mode org-activate-links ? Christopher Miles
@ 2021-02-13 3:33 ` Ihor Radchenko
2021-02-13 7:11 ` Christopher Miles
0 siblings, 1 reply; 4+ messages in thread
From: Ihor Radchenko @ 2021-02-13 3:33 UTC (permalink / raw)
To: Christopher Miles, Org Mode
Christopher Miles <numbchild@gmail.com> writes:
> I checked org-element-context source code, it's not so long and complex. Why it caused so many items in Memory profiler result? Is it possible to optimize it?
You can try to use org-element-cache. That might help.
Best,
Ihor
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Is it possible to optimize Org Mode org-activate-links ?
2021-02-13 3:33 ` Ihor Radchenko
@ 2021-02-13 7:11 ` Christopher Miles
2021-02-13 7:54 ` Ihor Radchenko
0 siblings, 1 reply; 4+ messages in thread
From: Christopher Miles @ 2021-02-13 7:11 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Org Mode
[-- Attachment #1.1: Type: text/plain, Size: 1301 bytes --]
<#secure method=pgpmime mode=sign>
Thanks for your hints.
Should I use the following options? I saw the warning. Does this freeze happens often? I decide to try it.
(defvar org-element-use-cache nil
"Non-nil when Org parser should cache its results.
WARNING: for the time being, using cache sometimes triggers
freezes. Therefore, it is disabled by default. Activate it if
you want to help debugging the issue.")
(defvar org-element-cache-sync-idle-time 0.6
"Length, in seconds, of idle time before syncing cache.")
(defvar org-element-cache-sync-duration 0.04
"Maximum duration, as a time value, for a cache synchronization.
If the synchronization is not over after this delay, the process
pauses and resumes after `org-element-cache-sync-break'
seconds.")
(defvar org-element-cache-sync-break 0.3
"Duration, as a time value, of the pause between synchronizations.
See `org-element-cache-sync-duration' for more information.")
Ihor Radchenko <yantar92@gmail.com> writes:
Christopher Miles <numbchild@gmail.com> writes:
I checked org-element-context source code, it's not so long and complex. Why it caused so many items in Memory profiler result? Is it possible to optimize it?
You can try to use org-element-cache. That might help.
Best, Ihor
[-- Attachment #1.2: Type: text/html, Size: 3387 bytes --]
[-- Attachment #2: ATT00001.txt --]
[-- Type: text/plain, Size: 253 bytes --]
--
[ stardiviner ]
I try to make every word tell the meaning that I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-02-13 7:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-02-13 1:10 Is it possible to optimize Org Mode org-activate-links ? Christopher Miles
2021-02-13 3:33 ` Ihor Radchenko
2021-02-13 7:11 ` Christopher Miles
2021-02-13 7:54 ` Ihor Radchenko
Code repositories for project(s) associated with this public 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).