Antora preview performance issues

[alaindresse]

Preview update performance is excessively slow (minutes to update a preview on an M1 Pro mac when the source is changed) in large repos with many symlinks (e.g. for nx monorepos with react-native apps and libs).

Using the proposed APIs for findFiles greatly improves the situation, but until that API is finalized, it can only be used with code insiders and it cannot be used in an extension published to the marketplace.

[alaindresse]

@ggrossetie a couple things I've seen in the code that might have an impact on performance.

• reading all files from modules/*/{attachments,examples,images,pages,partials,assets}/** for all antora folders. Is that necessary ?

  • in src/features/antora/antoraDocument.ts, in function getAntoraDocumentContext the code goes through all the antora configs, and for each config, finds all the files in the module folders, and reads the content in the line contents: Buffer.from((await vscode.workspace.fs.readFile(file))).
  • Doesn't this call do quite a lot of file reads (particularly if there are symlinks to e.g. source folders in partials) of which only a couple would actually be used when doing an include ?
    • .contents seems to be used in src/features/antora/includeProcessor.ts and src/features/antora/resolveIncludeFile.ts

• In src/features/asciidoctorExtensions.ts, function getExtensionFilesInWorkspace, do we really need a findFiles ? Couldn't we have a setting that identifies the one or more extension files to read (the list would probably not change that often).

[ggrossetie]

reading all files from modules/*/{attachments,examples,images,pages,partials,assets}/** for all antora folders. Is that necessary ?

I think we could potentially lazy load contents (i.e., load contents when we actually need it) but we need to retrieve all the files in order to build a "complete" content catalog.

[alaindresse]

reading all files from modules/*/{attachments,examples,images,pages,partials,assets}/** for all antora folders. Is that necessary ?

I think we could potentially lazy load contents (i.e., load contents when we actually need it) but we need to retrieve all the files in order to build a "complete" content catalog.

I was indeed referring to lazy loading the contents. The list of files is clearly needed for suggestions and completion.

[ggrossetie]

I was indeed referring to lazy loading the contents. The list of files is clearly needed for suggestions and completion.

I think that's an excellent idea, feel free to submit a pull request to lazy load the contents

[ggrossetie]

I remember now, include processor must be synchronous in Asciidoctor. So we cannot use vscode.workspace.fs.readFile(file) since it's an asynchronous function. I think that's the reason why we are eagerly loading contents.

[alaindresse]

What I would consider:

• Check if fs from node.js is available when we create the content catalog
  • If not available, we preload the contents to use as today
  • If so, we do not preload (e.g. setting contents to undefine), and we use fs.readFileSync in the include processor to add contents whenever contents is undefined.

[alaindresse]

Quite busy these days, but I'm not dropping the ball