[arch1t3cht]

With my current version of DependencyControl (0.9.0), any automation
script using DependencyControl imports no fewer than 47 MoonScript
files. Every automation scripts has its own isolated Lua environment, so
every script needs to compile its MoonScript files to Lua individually.

When enough such automation scripts are installed, the MoonScript-to-Lua
conversion alone makes up more than 90% of the CPU time when launching
Aegisub or rescanning the autoload folder.

Improve this situation by caching the binary blobs of loaded Lua or
MoonScript modules to the disk.

Some alternative approaches that were considered:

• Only caching the loaded chunks (or Lua transpile output) for MoonScript
  files and not also for Lua files.
  -> Benchmarks showed that even for Lua files, the time saved by the
  caching outweighs the cost of the additional file IO, see below.
• Caching the loaded chunks to memory and not to the disk.
  -> This would simplify some of the cache invalidation logic, but not
  improve the load time of the first loaded automation script.
  This is already quite significant; see the first-launch vs.
  second-launch comparisons below.
• Encouraging script distributors to transpile their MoonScript code to
  Lua prior to distribution.
  -> Apart from imposing extra effort, this makes local error messages
  less useful, makes it harder to locally patch scripts, and
  makes it harder to audit downloaded scripts.
• Making DependencyControl transpile the modules it installs to Lua or
  chunks.
  -> Has many of the same problems as the previous point.

The trickiest part is ensuring that cached chunks are properly
regenerated when the source files (or MoonScript) are updated.
Since we have full control over the cache file's format, we can build a
cache key out of not just the modification time, but also the size and
inode number (or some equivalent identifier that detects file moves).

Apart from that, we also need to make sure that the line_tables relating
compiled Lua source lines to MoonScript source lines (which are needed
for proper stack traces in error messages) are also preserved when
loading chunks directly from cache files.

On Windows, the file locking causes some difficulties when multiple
threads are trying to write the same cache file, so there we need to
make sure to not make errors due to locked files bloat the logs or
unnecessarily delay the loading.

Some numbers:

With a typical environment with around 25 DependencyControl-enabled
scripts installed, this results in the following reductions in
start time (wall-clock times via hyperfine on Linux):

• When loading all scripts on a single thread (replacing std::launch::async
  with std::launch::deferred in auto4_base.cpp):

  • Before this commit: 23.136 s ± 0.134 s
  • After this commit, first launch: 4.330 s ± 0.120 s
  • After this commit, second launch: 1.468 s ± 0.026 s

  -> Up to a 93% reduction

• When loading scripts on multiple threads (current behavior)

  • Before this commit: 6.258 s ± 0.209 s
  • After this commit, first launch: 4.166 s ± 0.302 s
  • After this commit, second launch: 1.944 s ± 0.249 s

  -> Up to a 68% reduction

Of course, the percentages will depend on the number of installed
automation scripts.

Note in particular that loading all scripts on one thread is now
faster on the second launch than loading them on different threads.
This is probably because the different DependencyControl instances are
fighting for the locks on their config files, but I haven't profiled
this in detail yet.

Caching only the chunks of MoonScript files and not of Lua files results
in a start time of 1.670 s ± 0.030 s on the second launch on one
thread, so also caching Lua files yields around a 12% improvement.

Options for future work:

• Rethink the multithreaded loading of scripts
• Somehow improve DependencyControl's locking, possibly by adding
  additional features to the Lua API
• Let automation scripts be loaded in the background instead of blocking
  Aegisub's launching on it

[arch1t3cht]

Should be genuinely ready now.