Kaushal Modi <kaushal.m...@gmail.com> writes: >> On latest main, your example file is exported without any warnings. >> > > I just verified that. Also, I did not even need to add > `(org-element-cache-reset)' in `org-hugo--get-pre-processed-buffer' after > the `(insert ..)' in the temp buffer. > > Is that expected?
Depends on your Emacs version. We had to disable the warning for Emacs<28 because some internal Emacs staff sometimes caused false-positives. However, if you tested using Emacs 28 or later, not seeing the warning is suspicious. > Let me know if you have any suggestions to improve the performance. I think > that the org-element-copy and writing the huge AST to temp Org buffer is > keeping the GC busy (the ox-hugo-manual.org is about 3700 lines right now). Just 145k buffer should normally cause no performance issues on Org side (on main). Even when you parse the whole buffer into AST. Problems begin around 5-10Mb. Yet, my 15Mb notes file is perfectly usable :D I looked through your `org-hugo--get-pre-processed-buffer': 1. org-element-copy should not be too much of an issue, unless you have many links. Yet, I am not sure why you need to use copy. You may as well modify the original element directly. 2. You call org-element-map twice making Org loop over the whole AST twice. 3. It is slightly more optimal to make your lambdas in org-element-map return nil. org-element-map allocates an extra list collecting all non-nil return values. If your lambda always returns nil, that list will not have to be created. Having said that, my local benchmarking did not show that org-hugo--get-pre-processed-buffer is a bottleneck. M-x profiler-start mostly revealed slowness of org-hugo--org-babel-exp-code, org-babel-expand-noweb-references, org-babel-sha1-hash, and org-macro-replace-all. Can you also try M-x profiler and see what is the bottleneck in your case? Best, Ihor
