#17229 implemented code path analysis in Oxlint JS plugins, primarily by copying code from ESLint.
There is huge scope to improve the implementation for better performance.
I've added a some comments to the code suggesting ways to improve it. There is some pretty low-hanging fruit there to be plucked!
|
// This is really inefficient code. |
|
// We could improve it in several ways (in ascending order of complexity): |
|
// |
|
// * Get rid of the bloated `VisitNodeStep` and `CallMethodStep` classes. Just use plain objects. |
|
// * Combine `step.kind` and `step.phase` into a single `step.type` property. |
|
// * Reduce object creation by storing steps as 2 arrays (struct of arrays pattern): |
|
// * Array 1: Step type (number). |
|
// * Array 2: Step data - AST node object for enter/exit node steps, args for CFG events. |
|
// * Alternatively, use a single array containing step objects as now, but recycle the objects |
|
// (SoA option is probably better). |
|
// * Avoid repeated conversions from `type` (string) to `typeId` (number) when iterating through steps. |
|
// * Generate separate `enterNode` / `exitNode` functions for each node type. |
|
// * Set them on `analyzer.original` before calling `analyzer.enterNode` / `analyzer.exitNode`. |
|
// * These functions would know the type ID of the node already, and then could store type ID in steps. |
|
// * When iterating through steps, use that type ID instead of converting `node.type` to `typeId` every time. |
|
// * Copy `CodePathAnalyzer` code into this repo and rewrite it to work entirely with type IDs instead of strings. |
|
// |
|
// TODO: Apply these optimizations (or at least some of them). |
Does anyone want to give it a go? No Rust knowledge required - it's pure TypeScript.