perf: add build stage analysis dimension and simplify project name inference

[xusd320]

Improvements

• Build Stage Analysis: Added a new dimension to agents/utoopack-performance-agent.md for analyzing performance across specific build phases (Resolve, Load, Transform, Analysis, Chunking, Finalization).
• Simplified Project Inference: Modified agents/tools/analyze_trace.py to prioritize the TRACE_PROJECT environment variable and removed complex auto-inference logic.
• Workflow Update: Updated .github/workflows/pack-perf.yml to use the TRACE_PROJECT variable for more reliable reporting.

[gemini-code-assist]

Summary of Changes

Hello @xusd320, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refines the performance analysis workflow by simplifying how project names are inferred and enhancing the guidance for build stage analysis. The core change involves streamlining the project identification mechanism in the analyze_trace.py script, making it more robust and explicit, and updating the associated documentation to reflect this new approach. This allows for more reliable and targeted performance reporting.

Highlights

• Project Name Inference Simplification: The analyze_trace.py script now prioritizes an override_project_name argument or the TRACE_PROJECT environment variable for identifying the project, removing previous complex path-based inference logic.
• Enhanced Build Stage Analysis Guidance: The documentation for utoopack-performance-agent.md has been updated to guide users on how to leverage the TRACE_PROJECT environment variable for more accurate build target identification, which is crucial for analyzing performance across specific build phases.
• Command Line Argument for Project Name: The analyze_trace.py script now accepts an optional command-line argument to directly specify the project name, offering more flexibility.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/pack-perf.yml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request simplifies how the project name is determined in the trace analysis script, prioritizing an environment variable and a new command-line argument over the previous file-path-based inference. The changes are also reflected in the documentation. My review includes suggestions to further improve the script's command-line interface by using argparse for more robust argument handling, and to enhance the documentation to clarify the different ways to specify the project name.

[github-actions]

📊 Performance Benchmark Report (with-antd)

🚀 Utoopack Performance Report: Async Task Scheduling Overhead Analysis

Report ID: utoopack_performance_report_20260202_092156
Generated: 2026-02-02 09:21:56
Trace File: trace_antd.json (1.5GB, 8.00M events)
Test Project: examples/with-antd

---

📊 Executive Summary

This report analyzes the performance of Utoopack/Turbopack, covering the full spectrum of the Performance Analysis Protocol (P0-P4).

Key Findings

Metric	Value	Assessment
Total Wall Time	10,519.8 ms	Baseline
Total Thread Work	90,171.9 ms	~8.6x parallelism
Thread Utilization	95.2%	✅ Good
turbo_tasks::function Invocations	3,882,833	Total count
Meaningful Tasks (≥ 10µs)	1,562,173	(40.2% of total)
Tracing Noise (< 10µs)	2,320,660	(59.8% of total)

Workload Distribution by Tier

Category	Tasks	Total Time (ms)	% of Work
P0: Runtime/Resolution	1,073,469	54,712.3	60.7%
P1: I/O & Heavy Tasks	37,877	3,576.1	4.0%
P3: Asset Pipeline	28,329	4,491.4	5.0%
P4: Bridge/Interop	0	0.0	0.0%
Other	422,498	20,213.1	22.4%

---

⚡ Parallelization Analysis (P0-P2)

Thread Utilization

Metric	Value
Number of Threads	9
Total Thread Work	90,171.9 ms
Avg Work per Thread	10,019.1 ms
Theoretical Parallelism	8.57x
Thread Utilization	95.2%

Assessment: With 9 threads available, achieving 8.6x parallelism indicates reasonable throughput.

---

📈 Top 20 Tasks (Global)

These are the most significant tasks by total duration:

Total (ms)	Count	Avg (µs)	% Work	Task Name
45,254.1	888,896	50.9	50.2%	turbo_tasks::function
8,576.9	126,551	67.8	9.5%	task execution completed
6,694.6	86,846	77.1	7.4%	turbo_tasks::resolve_call
2,973.2	32,919	90.3	3.3%	analyze ecmascript module
2,282.8	68,003	33.6	2.5%	precompute code generation
2,185.5	68,473	31.9	2.4%	resolving
1,822.5	36,524	49.9	2.0%	module
1,698.6	20,822	81.6	1.9%	effects processing
1,580.3	11,778	134.2	1.8%	process parse result
1,147.4	6,697	171.3	1.3%	parse ecmascript
1,112.4	36,272	30.7	1.2%	internal resolving
1,101.6	33,524	32.9	1.2%	process module
866.3	29,089	29.8	1.0%	resolve_relative_request
630.8	1,924	327.8	0.7%	analyze variable values
545.9	21,504	25.4	0.6%	handle_after_resolve_plugins
516.0	15,851	32.6	0.6%	resolve_module_request
464.2	1,947	238.4	0.5%	swc_parse
424.3	10,963	38.7	0.5%	code generation
420.6	17,779	23.7	0.5%	resolved
311.9	4,251	73.4	0.3%	read file

---

🔍 Deep Dive by Tier

🔴 Tier 1: Runtime & Resolution (P0)

Focus: Task scheduling and dependency resolution.

Metric	Value	Status
Total Scheduling Time	54,712.3 ms	⚠️ High
Resolution Hotspots	9 tasks	🔍 Check Top Tasks

Potential P0 Issues:

• Low thread utilization (95.2%) suggests critical path serialization or lock contention.
• 2,320,660 tasks < 10µs (59.8%) contribute to scheduler pressure.

🟠 Tier 2: Physical & Resource Barriers (P1)

Focus: Hardware utilization, I/O, and heavy monoliths.

Metric	Value	Status
I/O Work (Estimated)	3,576.1 ms	✅ Healthy
Large Tasks (> 100ms)	16	🚨 Critical

Potential P1 Issues:

• 16 tasks exceed 100ms. These "Heavy Monoliths" are prime candidates for splitting.

🟡 Tier 3: Architecture & Asset Pipeline (P2-P3)

Focus: Global state and transformation pipeline.

Metric	Value	Status
Asset Processing (P3)	4,491.4 ms	5.0% of work
Bridge Overhead (P4)	0.0 ms	✅ Low

---

💡 Recommendations (Prioritized P0-P2)

🚨 Critical: (P0) Improvement

Problem: 95.2% thread utilization.
Action:

1. Profile lock contention if utilization < 60%.
2. Convert sequential await chains to try_join.

⚠️ High Priority: (P1) Optimization

Problem: 16 heavy tasks detected.
Action:

1. Identify module-level bottlenecks (e.g., barrel files).
2. Optimize I/O batching for metadata.

⚠️ Medium Priority: (P3) Pipeline Efficiency

Action:

1. Review transformation logic for frequently changed assets.
2. Minimize cross-language serialization (P4) if overhead exceeds 10%.

---

📐 Diagnostic Signal Summary

Signal	Status	Finding
Tracing Noise (P0)	✅ Acceptable	59.8% of tasks < 10µs
Thread Utilization (P0)	✅ Good	95.2% utilization
Heavy Monoliths (P1)	⚠️ Detected	16 tasks > 100ms
Asset Pipeline (P3)	🔍 Review	4,491.4 ms total
Bridge/Interop (P4)	✅ Low	0.0 ms total

---

🎯 Action Items (Comprehensive P0-P4)

1. [P0] Investigate task scheduling gaps for incremental gains
2. [P1] Breakdown heavy monolith tasks (>100ms) to improve granularity
3. [P1] Review I/O patterns for potential batching opportunities
4. [P3] Optimize asset transformation pipeline hot-spots
5. [P4] Reduce "chatty" bridge operations if interop overhead is significant

---

Report generated by Utoopack Performance Analysis Agent on 2026-02-02
Following: Utoopack Performance Analysis Agent Protocol