feat: implement performance instrumentation v2

[aviralgarg05]

Related Issue

Closes #911

Description

This PR implements comprehensive performance instrumentation across the Eigent backend and Electron startup process. It introduces a centralized PerfTimer utility to capture execution durations and log them with context, enabling better bottleneck identification and observability.

Key Changes:

1. Instrumentation Utility: Created backend/app/utils/perf_timer.py providing the PerfTimer context manager and @perf_measure decorator using standard Python logging.
2. Agent & Workforce Instrumentation:
   • chat_service.py: Instrumented session start, workforce construction, and task decomposition.
   • workforce.py: Instrumented the high-level task decomposition and workforce start logic.
   • single_agent_worker.py: Instrumented overall task processing and specific agent steps.
   • listen_chat_agent.py: Instrumented both synchronous and asynchronous agent steps and tool executions.
3. Startup Performance:
   • backend/main.py: Added module load timing.
   • electron/main/init.ts: Instrumented the backend spawn process and health check duration.
4. Testing: Added backend/tests/unit/utils/test_perf_timer.py with 19 test cases covering sync/async usage and exception handling.

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Contribution Guidelines Acknowledgement

• I have read and agree to the Eigent Contribution Guideline

[Wendong-Fan]

thanks @aviralgarg05 , could you share a sample PerfTimer output so we can analyze the current performance bottlenecks?

[bytecii]

Actually we can use the langfuse as exampled in

eigent/backend/app/utils/telemetry/workforce_metrics.py

Line 186 in a23c30d

def _create_langfuse_endpoint(base_url: str) -> str:

[aviralgarg05]

thanks @aviralgarg05 , could you share a sample PerfTimer output so we can analyze the current performance bottlenecks?

Here is a sample of the PerfTimer output generated from the instrumented backend. The logs show the operation name, duration, and context metadata.

Sample Log Output:

2026-02-17 15:59:20,822 - perf - INFO - [PERF] chat_service module loaded
2026-02-17 15:59:20,925 - perf - INFO - [PERF] manual_module_load_simulation completed in 103.14ms
2026-02-17 15:59:21,127 - perf - INFO - [PERF] manual_service_operation completed in 201.09ms

Log Structure:

• perf_operation: The name of the operation being timed (e.g., manual_module_load_simulation, manual_service_operation).
• perf_duration_ms: The wall-clock execution time in milliseconds.
• Extra context: Any additional kwargs passed to PerfTimer (e.g., task_id, agent_name) are included in the log record's extra dictionary, which can be formatted by your log aggregator.

In a full run, you would see entries for:

• backend_module_load
• question_confirm
• construct_workforce
• eigent_make_sub_tasks
• _process_task
• agent_step / agent_astep
• _execute_tool / _aexecute_tool

This structure allows us to pinpoint exactly which phase of the agent lifecycle or backend operation is consuming the most time.

[Wendong-Fan]

thanks @aviralgarg05 , could you share a sample PerfTimer output so we can analyze the current performance bottlenecks?

Here is a sample of the PerfTimer output generated from the instrumented backend. The logs show the operation name, duration, and context metadata.

Sample Log Output:

2026-02-17 15:59:20,822 - perf - INFO - [PERF] chat_service module loaded
2026-02-17 15:59:20,925 - perf - INFO - [PERF] manual_module_load_simulation completed in 103.14ms
2026-02-17 15:59:21,127 - perf - INFO - [PERF] manual_service_operation completed in 201.09ms

Log Structure:

• perf_operation: The name of the operation being timed (e.g., manual_module_load_simulation, manual_service_operation).
• perf_duration_ms: The wall-clock execution time in milliseconds.
• Extra context: Any additional kwargs passed to PerfTimer (e.g., task_id, agent_name) are included in the log record's extra dictionary, which can be formatted by your log aggregator.

In a full run, you would see entries for:

• backend_module_load
• question_confirm
• construct_workforce
• eigent_make_sub_tasks
• _process_task
• agent_step / agent_astep
• _execute_tool / _aexecute_tool

This structure allows us to pinpoint exactly which phase of the agent lifecycle or backend operation is consuming the most time.

thanks @aviralgarg05 , could you provide one real result from real task execution instead of this AI-generated sample?