Resourse caching in sqlite

[KaruroChori]

Proposal

I just wanted to share few point for discussion about the caching mechanism I wanted to implement.
The idea is that:

• js/json/json5 resources from local fs are cached as bytecode in a sqlite table against the internal qjs version, the last modification date or the fs checksum for those filesystems providing it.
• wasm resources from a http/https resource are stored based on the cache policies of the reply without changes.
• js/json/json5 resources from a http/https resource are similarly stored as bytecode, with a lifetime based on the cache policies of the reply from server.

To further support this feature several functions/fields would be exposed:

• tjs.engine.prefetch(src,dst=undefined) taking a path or url & generating the corresponding bytecode+header to be saved either as file (mostly for debugging & the testsuite) or as an entry on the current database.
• tjs.cache.clean() to remove all outdated entries from cache, possibly filtered by some policy.
• tjs.cache.purge() to remove all entries from cache, possibly filtered by some pattern.

It is possible for json resources to save them as jsonb in place of qjs bytecode.
Direct support in engine for this format might be quite helpful, and sqlite has it as well.

This overall design would also help in handling the transpilation from typescript with little overhead during runtime.Basically ts files would just be transpiled and compiled once to bytecode, as long as they are not changed again.

Expected outcome

The highest positive impact will be when fetching remote resources, followed by those requiring transpilation steps and finally any native js locally stored.

There is no expectation for this implementation to result in worse performance compared to current, if not for marginal & artificially crafted cases.

Potential drawbacks

Filesystems without native support of an embedded checksum will have limited resolution in identifying changes to files against their cached version. This is because we are forced to fold back to the last date of change. In practice I do not expect this to be a realistic problem.
While it is technically possible for a program to continuously edit a js file and import it over and over, it seems to be an extremely artificial case with no realistic purpose.
Still we could just provide a flag for tjs to run without using this resource prefetching mechanism, and we should be good.

[saghul]

Interesting ideas! I'll give them a thought while I'm on vacation :-)

[saghul]

Python has had bytecode caching for a while, so we could borrow some inspiration: https://peps.python.org/pep-3147/

We'd need to expose the bytecode version in he QuickJS API so we can know if it's compatible or not, and it looks like it adds the file's mtime as a comparison point too.

Is this aligned with what you had in mind?

[KaruroChori]

I will have to give a look to PEP 3147.
But yes, we should expose the bytecode version both as a tjs.versions.bytecode and in the header of the compiled files themselves.
In addition to that, we also need to expose the library interface version, because bytecode alone does not tell us if breaking changes were done in the txiki core libraries.
If txiki followed semantic versioning this would be automatically implied, but since it does not an extra field would be needed.