GitHub user PG1204 added a comment to the discussion: RFC: Workflow Performance Profiler - full design & implementation walkthrough
Sounds good, we can discuss and cherry pick the required features. Reply to comments: 1) Yes, currently "WorkflowStatusService" has two concepts - "state" & "statistics". In my current impl, the "ProfilerService" is a separate service which subscribes to "WorkflowStatusService.getStatusUpdateStream()" as its input. Sure, I can extend the profile concept into "WorkflowStatusService", keeping it as the layer that contains the ground truth information. Worth noting that today operatorState and the aggregated counts share one flat OperatorStatistics record on a single stream, so part of sub-issue 1 will be splitting state and statistics into cleanly separated sub-concepts before adding the third. Also agreed on keeping user-facing language as "workflow status", I'll scrub "profile/profiler" from any UI surface. 2) Understood. I'll add the Heat Map as a single new sibling toggle in the Layers menu next to Grid / Regions / Workers / Status - reading from WorkflowStatusService and visualizing the new sub-concept. Future overlay layers can come in as separate work later. Reply to PR plan: This plan sounds good. I'll go ahead and work the three suggested changes. Umbrella issue title: since "profile/profiler" is off the table, something like "Workflow status overlays and ground-truth refactor", or do you have any preferred phrasing? Sub-issue 3 scope: should "same information after refresh" cover both live (mid-execution reconnect) and post-execution (loading a completed run), or only one of those for now? Is it alright if I add you as the reviewer for all the three sub issues' PRs? GitHub link: https://github.com/apache/texera/discussions/5216#discussioncomment-17068690 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
