-
-
Notifications
You must be signed in to change notification settings - Fork 0
enable plugins to declare pooled/deferred traversals #4
Comments
Background/Motivation This idea is primarily motivated by the potential to improve performance by reducing another form of cross-tool duplicate logistical work (Unified already trims a few). This is admittedly speculative; the tools I'm already using are doing a fair amount of overlapping work, but I may be overestimating how much runtime the overlap represents. I think demonstrated improvement is a key measuring stick for any proof-of-concept (willing to pull one together; not sure about timeline, though). Beyond the primary motive, I suspect a declarative traversal pattern will help separate what a plugin does from what the plugin does it to, which might make it easier to re-use plugins in contexts that the plugin writer didn't anticipate. |
FWIW, interested in doing the same/similar with tokenizing, but it's probably off topic here (I think traversal makes a cleaner test-case, and it might be one or more separate plugins anyways). |
Implementation
|
Well, for starters, we could create a new plugins that adds this to TraverseI’m thinking of a
Pool
Further thoughts
|
Thanks for starting the discussion @abathur ! |
Laying this out over a few focused comments for digestibility.
I'm curious about enabling plugins to declare traversals they're interested in during a setup phase, pool those traversals across plugins, and execute a single walk to satisfy them in a later phase.
The text was updated successfully, but these errors were encountered: