You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
My one-subtree-per-blog-post file is 9600 lines (85000 words), and
the blog post/subtree I am exporting in this test is 1820 lines (around 11800 words).
56% of the time is spent in org-hugo-export-wim-to-md, of which 41% is spent in org-export-as and 14% in org-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 about org-hugo--get-pre-processed-buffer.
My understanding of the ox-hugo export process is the following:
Parse the full original buffer into an AST,
Replace org links in the AST with a Hugo-appropriate link
Write this AST back as Org into temporary buffer 1.
Export the subtree in temporary buffer 1 using org-export-to-file.
This is done via org-export-as, which makes another copy of the full buffer using org-export-with-buffer-copy into temporary buffer 2,
before narrowing to the subtree and performing the required transformations.
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:
Is there no way to export a subtree with only one copy of the full buffer, as created by 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.
I am not familiar with the one-post-per-org-file export method. Is that likely to be any faster for my Org file? I was hoping for some insight before breaking up my file into smaller ones and working out the kinks.
Ox-Hugo Debug Information
Debug Info
Debug information for ox-hugo
Emacs Version
GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
Org Version
Org mode version 9.7-pre (76468c364 @ /home/karthink/.local/share/git/straight/build29/org/)
Hugo Version
hugo v0.111.3+extended linux/amd64 BuildDate=unknown VendorInfo=nixpkgs
Here are the results of profiling with elp. Everything is slightly slower because of the instrumentation, but here it appears that org-hugo-get-preprocessed-buffer takes up more than half the time -- I assume this means it's the main cause of the garbage collections, which are not captured independently by elp.
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-md
takes 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-as
and 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-copy
into 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-hugo
Emacs Version
Org Version
Hugo Version
Org
load-path
shadowsWarning: Possible mixed installation of Org
Study the output of
M-x list-load-path-shadows
.ox-hugo
defcustomsThe text was updated successfully, but these errors were encountered: