tl;dr: `:exports results :noweb no-export :eval never-export' needlessly expands <<noweb>> code causing massive slowdowns on export.
> On Jun 13, 2018, at 9:42 PM, Ken Mankoff <mank...@gmail.com> wrote: > > One more thought - even if your system is significantly faster for some > unknown reason - why is export taking ~15 seconds for 200 blocks *when you > aren't exporting any of the code*. > Why is <<noweb>> expansion occurring if ":eval never-export" is set? There > seems to be something inefficient going on here. > > Using your ECM, C-c C-v C-i on your `baz' block. Note `:exports code' ,---- | Name: baz | Lang: sh | Properties: | :header-args :eval never-export | :header-args:sh nil | Header Arguments: | :cache no | :eval never-export | :exports code | :hlines no | :noweb yes | :results verbatim replace | :session none | :tangle no `---- Setting `:exports none' speeds things up a bit more. Looking back at your earlier posts, I see that you had `:exports results' for your python block but not in your ECM. i.e. you need these header args: #+PROPERTY: header-args :eval never-export :exports results :noweb no-export to show how bad things can be in your ECM. The `:exports results' will *really* slow things down. And this *may* be considered a bug. Babel isn't quite smart enough to sort out that you want results, but do not need to eval the src block nor check the hash in `org-babel-sha1-hash'. Making matters a bit more complicated, I'd have thought that this :noweb (if org-export-current-backend "no" "yes") would be enough to fix things, but it fails on recursive noweb expansions if you try to execute a src block interactively. And maybe that is a bug, too. HTH, Chuck