With the advent of OtherLoader, the runtime stage has been put to the test. Unfortunately, it fell short. Its predecessor, LSIIC, began loading all bundles as soon as possible. Due to runtime stage constraints, OtherLoader can only do one glob of files at a time. For this reason, OtherLoader's first iteration was slow.
It has since been fixed by having the loader immediately yield break, but this is not a good solution.
For one, it contradicts the runtime stage. Why bother yield returning anything (which slows down loading), when a coroutine can be run in the background?
Additionally, it undermines dependency safety. Consider mods A and B, as well as items A and B. Mod A contains item A. Mod B contains item B, a larger item that references item A. For this reason, mod A is a dependency of mod B. Mod A begins to load and finishes quickly, but item A is not finished loading. Mod B follows suit, and now item B is trying to load before item A is accessible.
I think the best solution would be to calculate the dependency tree, and work up it in n parallel coroutines. This number should be a config as well.
This would bring the accelerated runtime loading of OtherLoader to all Deli mods with a runtime stage, and it would bring back dependency safety to OtherLoader.
With the advent of OtherLoader, the runtime stage has been put to the test. Unfortunately, it fell short. Its predecessor, LSIIC, began loading all bundles as soon as possible. Due to runtime stage constraints, OtherLoader can only do one glob of files at a time. For this reason, OtherLoader's first iteration was slow.
It has since been fixed by having the loader immediately
yield break, but this is not a good solution.For one, it contradicts the runtime stage. Why bother
yield returning anything (which slows down loading), when a coroutine can be run in the background?Additionally, it undermines dependency safety. Consider mods A and B, as well as items A and B. Mod A contains item A. Mod B contains item B, a larger item that references item A. For this reason, mod A is a dependency of mod B. Mod A begins to load and finishes quickly, but item A is not finished loading. Mod B follows suit, and now item B is trying to load before item A is accessible.
I think the best solution would be to calculate the dependency tree, and work up it in
nparallel coroutines. This number should be a config as well.This would bring the accelerated runtime loading of OtherLoader to all Deli mods with a runtime stage, and it would bring back dependency safety to OtherLoader.