Filesystem Cache

[branchseer]

It's a much-requested feature in rollup: rollup/rollup#2182. Although rollup only supports in-memory cache (--watch).

For rolldown, I think filesystem cache is more important than in-memory cache since it's meant to be a production bundler for vite.

I have some primitive ideas to try but I want to ask if this is interested before digging in.

[hyf0]

Thanks for caring about it. Filesystem Cache is definitely something we are going to think about. However, it's a little bit early to say how we gonna do it. I mean we have built abstraction of file system, which might be a good start. But we don't have a cache design both for memory and file system so far.

[branchseer]

Hi @hyf0,

In the implementation of --watch, rollup starts from scratch everytime but caches and reuses results of individual modules: rollup/rollup#191 (comment).

I like this method, and think it can also be a good start for fs cache as it's easy to reason about and non-invasive to the existing workflow.

For rolldown, if we are taking this approach, I think it would mean caching and reusing

rolldown/crates/rolldown/src/module_loader/normal_module_task.rs

Line 75 in a031226

let (ast, scope, scan_result, ast_symbol, namespace_symbol) = self.scan(&source);

What do you think of this approach? Would you be interested in a PoC implementation? I've already had some success on (de)serializing oxc ast nodes and semantic analysis results.

[branchseer]

Deserializable oxc types: oxc-project/oxc#3079

[Boshen]

@branchseer Let me DM the Rolldown team on this.

I wonder whether persistent cache is useful given Rolldown is going to be so fast 🤔 People wanted it because Rollup is slow.

Oxc can parse (and eventually transform) files really fast, e.g. running the linter without any rules

pnpx oxlint@latest -A all
Finished in 5.3s on 70392 files with 0 rules using 12 threads.

This means we should persist other artifacts in Rolldown instead of the ASTs?

[branchseer]

I just did a quick bench against NormalModuleTask::scan and scan output deserialization: https://github.com/branchseer/rolldown/blob/deser_bench/crates/rolldown/benches/scan.rs.

On my machine it took 26.447 ms to scan a 1.3MB js module, and 8.4845 ms to deserialize the scan output using bincode2. That's about 3 times as fast as a module scan.

I agree that its usefulness depends on how fast rolldown can become. Reducing 300ms to 100ms is not as useful as reducing 3s to 1s.

The bench is a very rough one and leaves some questions to be answered:

• rkyv is said to be faster that bincode. I wonder how much faster we can get in this case.
• How much IO time can be saved? We can read all caches from a single db file, maybe memory-mapped, while source files scatter across the disk. Although cache invalidation still requires reading source file metadata from the fs catalog.

[Boshen]

Most js files are just a few hundred lines, so the difference may not be this large.

---

This discussion is about persistent cache for the whole build pipeline, so I recommend looking into other data to persist before going down the rabbit whole of persisting the AST, which requires a lot of effort and infrastructure.

[branchseer]

I choose the scan part to start with because it's the first step and mostly pure, so caching it requires little change to existing code. Rolldown is still evolving rapidly after all.

But yeah I think I should profile the whole build process to find what parts are worth caching. Then again maybe it's too early to get a meaningful result.

[overlookmotel]

@hyf0 Just wanted to check how much of a gain you think a persistent cache for ASTs would be.

For the sake of argument, let's say the following is possible:

• Write out AST + semantic data for a JS/JSX/TS file to disk (either pre- or post-transform) with minimal serialization overhead.
• Read it back from disk into memory with zero deserialization cost. Just load into memory and cast a pointer.

If this were possible, would it be a large gain for Rolldown? Or is parsing/semantic/transform fast enough anyway that disk caching isn't particularly worthwhile?

I'm asking because I'm thinking about a custom allocator for Oxc (and accompanying custom Box and Vec). Design would be influenced by what use cases are most important to support. Some possible designs could support the above, though there are trade-offs, so am wondering if this is a priority use case or not.

[hyf0]

If this were possible, would it be a large gain for Rolldown?

It should takes advantages on the very large scale project, but it only can be sure with practices.

For normal caching, I guess we are just comparing the performance between oxc-parser and serde_json/rkyv? From what Boshen said, differences would be probably subtle. #802 (reply in thread)

In the bigger picture, the caching might doesn't need to touch ast and will only need to cache the codegen result of ast.

---

So I guess you don't need to take the caching ast as a important part while constructing a custom allocator.

[overlookmotel]

Thanks for coming back. Just to clarify:

What I have in mind is a no-serialization implementation. AST types would be stored in allocator in a format where you can just dump the allocator's memory buffer to disk with no serialization step - literally just copy memory to disk with no processing. In other direction, loading it back into memory is also purely load bytes from disk into memory, with no deserialization step. No overhead of serde/rkyv.

So the comparison isn't parser vs serde, but parser vs disk IO.

I know this is an unusual approach, but arena allocator (if built in a certain way) allows some stuff you can't usually do. So, in the context of this question, try to forget everything you know about how things usually work! Assume that ser/deser is 100% free.

I'm not familiar with Rolldown's internals, but don't you need to work with ASTs in order to link files together to build chunks? (rather than working with compiled JS code)

Does any of that affect the answer?