Introduce an async convert #644
Conversation
|
|
||
| # If a VFS is defined, Asciidoctor will use it to resolve the include target. | ||
| # Otherwise use the file system or the network to read the file. | ||
| def read_include_content inc_path, target_type |
There was a problem hiding this comment.
@mojavelinux preprocess_include_directive method is almost identical, I've just replaced File.open with the new read_include_content method.
ggrossetie
force-pushed
the
master
branch
7 times, most recently
from
4e17c44
to
c9a1041
Compare
It's annoying that Node.js doesn't provide this out of the box. I run into the same problem whenever I switch to async operations. |
|
I'm not sure that overriding/importing large chunks of Asciidoctor core is the right idea here. But I'm also still at a loss for exactly how to handle this. We don't really have a true preprocessor that avoids side effects in Asciidoctor, and the include directive is inherently synchronous. This is topic I think we need to consider in the AsciiDoc Language project, then carry out whatever we decide after the architecture is worked out there. |
Readerclass in Asciidoctor core has a new methodread_include_contentconvertAsyncfunction will fetch the content of all the unconditional includes and populate the VFS.Performance wise it about the same speed for local files but since the event loop is not blocked (or at least less blocked), the performance should be better on a running application.
I think we should be careful about how many asynchronous remote calls we can make at once. We may need to set a limit to avoid resource exhaustion.
Using a cache greatly improve performance if a remote file is present more than once in the document. For reference
open-uri/cachedmodule used in Asciidoctor Ruby is not available in JavaScript.