-
Improvement
-
Resolution: Done
-
Major
-
None
In most cases we only care about the directly attached actions on flownodes. FlowNode.getAction has been identified as ~25% of runtime for pipeline flow analysis, and it is likely b/c this queries all TransientActionFactories for actions.
We should:
1. Add a FlowNode.getAction API version (name TBD) that only iterates through the directly added actions (already cached in-object)
2. Switch the pipeline-graph-analysis plugin and stage view's REST API to use this exclusively
3. Benchmark to see what the performance difference is
UPDATE: Doubles stage view performance, which should carry through to a large extent anywhere we use flow analysis.
- is blocked by
-
JENKINS-40281 No Badge shown, Exception build.badgeActions depending on KeepBuildForever
-
- Resolved
-
[JENKINS-38867] Major Optimization: Create and Use FlowNode.getAction w/o TransientActionFactories
Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Status | Original: In Progress [ 3 ] | New: In Review [ 10005 ] |
Description |
Original:
In most cases we only care about the directly attached actions on flownodes. FlowNode.getAction has been identified as ~25% of runtime for pipeline flow analysis, and it is likely b/c this queries all TransientActionFactories for actions. We should: 1. Add a FlowNode.getAction API version (name TBD) that only iterates through the directly added actions (already cached in-object) 2. Switch the pipeline-graph-analysis plugin and stage view's REST API to use this exclusively 3. Benchmark to see what the performance difference is |
New:
In most cases we only care about the directly attached actions on flownodes. FlowNode.getAction has been identified as ~25% of runtime for pipeline flow analysis, and it is likely b/c this queries all TransientActionFactories for actions. We should: 1. Add a FlowNode.getAction API version (name TBD) that only iterates through the directly added actions (already cached in-object) 2. Switch the pipeline-graph-analysis plugin and stage view's REST API to use this exclusively 3. Benchmark to see what the performance difference is UPDATE: *50% improvement in stage view performance, which should carry through to a large extent anywhere we use flow analysis.* |
Component/s | Original: pipeline-graph-analysis-plugin [ 21693 ] | |
Component/s | Original: pipeline-stage-view-plugin [ 21139 ] |
Description |
Original:
In most cases we only care about the directly attached actions on flownodes. FlowNode.getAction has been identified as ~25% of runtime for pipeline flow analysis, and it is likely b/c this queries all TransientActionFactories for actions. We should: 1. Add a FlowNode.getAction API version (name TBD) that only iterates through the directly added actions (already cached in-object) 2. Switch the pipeline-graph-analysis plugin and stage view's REST API to use this exclusively 3. Benchmark to see what the performance difference is UPDATE: *50% improvement in stage view performance, which should carry through to a large extent anywhere we use flow analysis.* |
New:
In most cases we only care about the directly attached actions on flownodes. FlowNode.getAction has been identified as ~25% of runtime for pipeline flow analysis, and it is likely b/c this queries all TransientActionFactories for actions. We should: 1. Add a FlowNode.getAction API version (name TBD) that only iterates through the directly added actions (already cached in-object) 2. Switch the pipeline-graph-analysis plugin and stage view's REST API to use this exclusively 3. Benchmark to see what the performance difference is UPDATE: *Doubles stage view performance, which should carry through to a large extent anywhere we use flow analysis.* |
Resolution | New: Done [ 10000 ] | |
Status | Original: In Review [ 10005 ] | New: Closed [ 6 ] |
Component/s | New: core [ 15593 ] |
Link |
New:
This issue is blocked by |