ComfyUI generations report wall time only; split queue / execution / download timing
Problem
Today the only duration signal around a ComfyUI generation is wall time. On a shared or busy server, wall time conflates three very different things:
- queue wait — time between
submit()and the server starting execution - actual prompt execution — real GPU/workflow time
- download — artifact transfer
Cost tracking, capacity planning, and timeout tuning all need these split. Right now an agent reporting "generation took 240s" cannot tell whether the GPU was busy for 230s or the job sat in queue for 200s.
Proposed change
Add lightweight timing instrumentation to ComfyUIClient.generate():
- record
submit_s,client_queue_and_poll_s,download_sfrom the client's own clock (time.perf_counter) - read server-side execution time from the history entry's
execution_start→execution_successtimestamps (ComfyUI already records these; needs ms-vs-s normalization since servers differ) - expose the result as
client.last_timing(dict,Nonebefore first run) so any caller —comfyui_video,comfyui_image,comfyui_music— can surface it in result data without API changes
Surface result.data["timing"] in comfyui_video (and ideally the other ComfyUI tools) including wall_s and the derived comfy_prompt_exec_s.
No schema changes, no new dependencies, backwards compatible (callers that ignore last_timing see no difference).
Happy to send a PR with unit tests (history timestamp parsing incl. ms/s normalization, and the generate() instrumentation with a faked client).
Source: calesthio/OpenMontage