lazy config

[mbostock]

This defers loading of the config until a request is made, such that when the page is reloaded, we can always grab the latest config. This means you don’t have to restart the preview server in order to see config changes.

Fixes #645.
Fixes #646 (although, doesn’t push the change down — you still have to reload).

[mbostock]

Hmm, so a downside of this approach is that if you don’t have any config file, every request requires materializing the default config (which includes crawling the docs folder to find all pages). That’s kind of a bummer. I’m not sure how to solve that… probably recording the current time before you load the config, and then invalidating the previously-cached config if any Markdown file within the root is newer than the last load time?

[Fil]

I think #702 is enough to solve the performance issue you mention. What's slow is not reading the files, but parsing them. In my tests at least, using #702 with this branch makes it go from "noticeably slow" to "instant" (← scientific precision).

[Fil]

want!

[Fil]

tested with #765 this works very well

[mbostock]

I no longer notice any slowness when there’s no config file, probably because we rewrote the parser in #843 which means we do a lot less within parseMarkdown than we used to (less rendering). What do you think @Fil? Is this good enough as-is or should we add the memoization from #702 into this PR?

[Fil]

On my machine the preview server needs 1.1s to read the 300 pages of pangea. So that gives me an estimate of about 3ms per page. That's probably fine for medium-sized projects (of course for a large project you wouldn't rely on the default config).

However I noticed that a page that loads 20 _esm.js resources will pay this cost 20 times, so that's now 60ms per page. Even for a medium project this might add up to too much time.

But, I think it points to a simple optimization—pay this cost only once every few seconds. Adding a simple memoization of the result of readConfig completely fixes the issue instantly.

 async _readConfig() {
    const t = +new Date();
    if (_mem.until > t) return _mem.config;
    _mem.until = t + 12000;
    return _mem.config = readConfig(this._config, this._root)
  }

I don't think it's a blocker, and can be worked on as a follow-up.

[mbostock]

I can take a look at memoizing just readPages, too… I think we could make that cheap by just checking if any of the files have been modified, or if the set of files has changed. Scanning the directory should be cheap.

I’m surprised that _esm.js resources make a difference, though? parseMarkdown doesn’t do any import resolution — that happens in getResolvers and so we shouldn’t be paying for that inside readPages. Is it possible that you were measuring the rendering cost rather than the parsing cost?

[Fil]

I don't know exactly as I am only looking at the network tab in the inspector. Each resource served has the same ~1s latency.

[mbostock]

a page that loads 20 _esm.js resources will pay this cost 20 times

Ah, sure, that’s because each request to the preview server, including the linked resources, will load the config.

[mbostock]

The latest commit makes the default config.pages (and config.sidebar by extension) a getter, such that it’s only computed on-demand, and recomputed as necessary. This fixes two problems: it avoids computing pages when not needed (e.g., serving _esm.js), and it recomputes pages as needed so that it reflects the contents of the source root at the time it is needed (which could change independently of the config file being edited!).

This feels nice! I think we could further add caching to readPages, but I don’t think it’s a blocker.

[Fil]

This seems to have removed the memoization of the minisearch index.

[mbostock]

I don’t see that… but it is loading pages because that’s destructured within searchIndex before it checks the cache.

[mbostock]

It does break the linkCache in the page’s findLink when pages is undefined…

[Fil]

I've confirmed the problem with a brand-new clone of the repo: after this commit minisearch.json is now recreated every time, which makes the search slow in preview.

Because it's memoized in a WeakMap indexed with the config:

const indexCache = new WeakMap();
...
indexCache.set(config, …)

To fix we could just memoize it independently of the config. But for now… good night!

[mbostock]

Fix in #1129!