Subtree export takes 8+ seconds #732
Comments
karthink
changed the title
|
Here are the results of profiling with
|
|
I'm having the same issue. After setting My guess is that it's related to the link processing as I have a lot org-roam links in the org file, even though most links are not in the exported subtree. |
|
I'm having the same issue. After setting `(setq org-hugo--preprocess-buffer nil)` (based on #589 ), the speed is normal but I figure it's not a proper fix.
ox-hugo parses the entire file even if you're publishing a subtree so it can resolve internal links and convert them to links between pages in your blog. If you turn off buffer preprocessing, those links will not be resolved and you'll have broken links (I think). You can work around this by turning off preprocessing, then not using internal Org links between parts of your file, and instead using http links to where you know the content is (or will end up). But yeah, it's not a general solution.
The code could also be modified so that only the specific outgoing links from the subtree to be exported to the rest of the buffer are resolved, instead of resolving all internal links in the document. But this is not the bottleneck, running org-element-parse-buffer on a large file is, so it doesn't help much.
org-element-parse-buffer (and its equivalents) do not scale well as the size of the document grows, in both CPU time and memory.
|
|
I am sorry guys; I cannot help much here. Recent versions of Org have broken the buffer preprocessing logic and as of now, linking to other subtree-based posts in the same Org file is completely broken. I need help fixing this: #755 |
This is not exactly a bug, more of a question about the export times of ox-hugo and whether this is typical.
Actual Behavior
org-hugo-export-wim-to-mdtakes a long time:This is when exporting a subtree with
C-c C-e H H. Is this typical?Expected Behavior
A < 2 second export time would be great.
How to Reproduce the Issue
I'm not sure, but having a reasonably large Org file with links and babel blocks is probably enough. (Note: I don't eval babel blocks on export.) I can no longer use export-on-save, which I used to a couple of years ago when the file was much smaller (< 3000 lines).
Profiler report here.
The short version is that:
42% of the time is spent in GC
56% of the time is spent in
org-hugo-export-wim-to-md, of which 41% is spent inorg-export-asand 14% inorg-hugo--get-pre-processed-buffer.Some thoughts
I'm guessing there isn't much we can do about
org-export-as, as it's the standard export mechanism. But I was wondering aboutorg-hugo--get-pre-processed-buffer.My understanding of the ox-hugo export process is the following:
org-export-to-file.org-export-as, which makes another copy of the full buffer usingorg-export-with-buffer-copyinto temporary buffer 2,So there are two at least two temp buffers being created that contain full copies of the original org file, and creating the first one involves parsing the original buffer with org-element into an AST, modifying it and writing it as Org again. This probably also explains the large number (and duration) of garbage collections.
This got me wondering:
org-export-as? Perhaps the link resolution can be done in the original buffer, with the destination links passed as metadata in the INFO plist used during exports. This would go a long way towards reducing the GC time and overall export duration.Ox-Hugo Debug Information
Debug Info
Debug information for
ox-hugoEmacs Version
Org Version
Hugo Version
Org
load-pathshadowsWarning: Possible mixed installation of Org
Study the output of
M-x list-load-path-shadows.ox-hugodefcustomsThe text was updated successfully, but these errors were encountered: