ITADN

perf: parallelize CUSTOM_RESOURCES collection probes at startup?

#377OpenNearlCrews 创建于 2026-05-23
N
NearlCrewscommented
At startup, `FBCustomResourceService.initCustomCollections` issues `checkCustomCollection` for each entry in `app.CUSTOM_RESOURCES` serially: https://github.com/SignalK/freeboard-sk/blob/v2.23.0/src/app/modules/skresources/custom-resources-service.ts#L48-L57 ```ts public async initCustomCollections() { const rcs = {}; for (const cr of this.app.CUSTOM_RESOURCES) { let r = await this.checkCustomCollection(cr.name, cr.description); rcs[cr.featureKey] = r; } return rcs; } ``` Each `checkCustomCollection` does a GET to `/signalk/{skApiVersion}/api/resources/{name}` and, on failure, a POST to `/plugins/resources-provider/_config/{name}` (lines 68-89). With N custom resources, startup pays N sequential round trips before `getFeatures()` resolves. The probes are independent: - Each writes its own `rcs[cr.featureKey]` slot, no shared state. - `checkCustomCollection` already converts GET/POST failures into `resolve(false)`, so no probe rejects. Would a `Promise.all` batch here be welcome? The change is one block: ```ts public async initCustomCollections() { const rcs = {}; await Promise.all( this.app.CUSTOM_RESOURCES.map(async (cr) => { rcs[cr.featureKey] = await this.checkCustomCollection(cr.name, cr.description); }) ); return rcs; } ``` I have it on a fork branch (`perf/parallel-custom-collections`); happy to open the PR if it fits the roadmap, otherwise I'll keep it local. Happy to capture before/after wall-clock numbers if that would help.
2 条评论