Ihor Radchenko writes:
> Most of the CPU time is spent in org-babel-tangle-collect-blocks, which
> is basically another regexp search for all the source blocks in buffer.
> The scaling is still slightly non-linear - maybe your source block
> regexp is too complex:
After further investigation I
Ihor Radchenko writes:
> pareto optimal writes:
>
>> Using =emacs -Q= to tangle org files with more than over 100 noweb-refs gets
>> slow fast.
>>
>> Given this org code for N=2:
>> Using Gcc Emacs 28.0.91 (which I typicall use) I get these results:
>>
>> | N blocks | runtime | # of GCs |
>>
Sébastien Miquel writes:
> pareto optimal writes:
>> Using =emacs -Q= to tangle org files with more than over 100
>> noweb-refs gets slow fast.
> I can reproduce the slow down with my config. The culprit is
> ~org-element--cache-verify-element~. Significantly decreasing
>
pareto optimal writes:
> Using =emacs -Q= to tangle org files with more than over 100 noweb-refs gets
> slow fast.
>
> Given this org code for N=2:
> Using Gcc Emacs 28.0.91 (which I typicall use) I get these results:
>
> | N blocks | runtime | # of GCs |
> |--+-+--|
> |
Hi,
pareto optimal writes:
Using =emacs -Q= to tangle org files with more than over 100
noweb-refs gets slow fast.
I can reproduce the slow down with my config. The culprit is
~org-element--cache-verify-element~. Significantly decreasing
=org-element--cache-self-verify-frequency= yields a 5x
Using =emacs -Q= to tangle org files with more than over 100 noweb-refs gets
slow fast.
Given this org code for N=2:
#+begin_src org :tangle 2.org
,#+begin_src elisp :noweb yes :tangle 2.el
<>
,#+end_src
,#+begin_src elisp :noweb-ref some-reference :tangle no
;; comment
,#+end_src
