in world.ts, we have the following code, which is in need of more cleverness. It will group most systems by themselves, as it is now, which is very bad, especially once we figure out how to go multi-threaded.
The objective of this story is to get rid of the below mentioned todos.
// todo: improve logic which sets up the groups
protected prepareExecutionPipeline(state: IState): Set<TSystemInfo<any>>[] {
// todo: this could be further optimized by allowing systems with dependencies to run in parallel
// if all of their dependencies already ran
// todo: also, if two systems depend on the same components, they may run in parallel
// if they only require READ access
const result: Set<TSystemInfo<any>>[] = [];
const stateSystems = Array.from(state.systems);
let executionGroup: Set<TSystemInfo<any>> = new Set();
let shouldRunSystem;
let systemInfo: TSystemInfo<any>;
if (!this.sortedSystems || this.dirty) {
// this line is purely to satisfy my IDE
this.sortedSystems = [];
this.maintain();
}
for (systemInfo of this.sortedSystems) {
shouldRunSystem = !!stateSystems.find(stateSys => stateSys.constructor.name === systemInfo.system.constructor.name);
if (shouldRunSystem) {
if (systemInfo.dependencies.size > 0) {
result.push(executionGroup);
executionGroup = new Set<any>();
}
executionGroup.add(systemInfo);
}
}
result.push(executionGroup);
return result;
}
The changes in the new scheduler make this topic outdated. There still are issues with system sorting, but I will try to come up with more actionable issues or implement stuff on the side!
in
world.ts
, we have the following code, which is in need of more cleverness. It will group most systems by themselves, as it is now, which is very bad, especially once we figure out how to go multi-threaded.The objective of this story is to get rid of the below mentioned todos.