⚡ Bolt: [performance improvement] 중간 배열 할당 방지를 통한 렌더링 성능 최적화 - #496
⚡ Bolt: [performance improvement] 중간 배열 할당 방지를 통한 렌더링 성능 최적화#496seonghobae wants to merge 3 commits into
Conversation
…on for placeholder rendering
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
There was a problem hiding this comment.
Pull request overview
This PR applies a small render-path micro-optimization in the desktop UI by switching placeholder-element generation from Array.from({ length }).map(...) to Array.from({ length }, mapFn) to avoid an extra intermediate array allocation during JSX rendering.
Changes:
- Update
Workspacetimeline decoration rendering to useArray.from’s mapper argument (and add a brief performance note). - Update
Appsidebar decoration rendering to useArray.from’s mapper argument. - Document the optimization rationale in
.jules/bolt.md.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| apps/desktop/src/features/workspace/Workspace.tsx | Uses Array.from({ length }, mapFn) for decoration spans (and adds an inline perf comment). |
| apps/desktop/src/App.tsx | Uses Array.from({ length }, mapFn) for sidebar decoration spans. |
| .jules/bolt.md | Adds a learning entry documenting the allocation avoidance pattern. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| <div className="relative min-w-[720px] border-t border-white/10 px-3 py-6" aria-hidden="true"> | ||
| <div className="flex h-24 items-center gap-1 overflow-hidden"> | ||
| {Array.from({ length: 84 }).map((_, index) => ( | ||
| {/* Performance: Avoid creating intermediate array of undefined items by passing a mapping function to Array.from directly */} |
OpenCode Review Overview
Pull request overviewOpenCode reviewed the current-head evidence but found unresolved reviewer or review-agent threads before approval. Findings1. HIGH .github/workflows/opencode-review.yml:1 - Unresolved reviewer thread blocks automated approval
Review thread evidenceLatest unresolved reviewer thread evidence
|
There was a problem hiding this comment.
Pull request overview
OpenCode reviewed the current-head evidence but found unresolved human review threads before approval.
Findings
1. HIGH .github/workflows/opencode-review.yml:1 - Unresolved human review thread blocks automated approval
- Problem: OpenCode reached an APPROVE control result, but the approval step found unresolved, non-outdated human review thread evidence on the current pull request.
- Root cause: Human review feedback can arrive after bounded model evidence is prepared, so the approval step must re-query GitHub immediately before publishing an approval.
- Fix: Address or resolve the listed human review thread(s), then re-run OpenCode on the current head.
- Regression test: Keep the approval gate querying reviewThreads(first: 100) after model output and before create_pull_review APPROVE.
Review thread evidence
Latest unresolved human review thread evidence
apps/desktop/src/features/workspace/Workspace.tsx line 99
-
Latest human comment: @copilot-pull-request-reviewer at 2026-07-01T02:40:07Z
-
Comment URL: #496 (comment)
-
Comment excerpt: Inline JSX performance comment is unusually long and (based on a repo-wide search) this is the only
/* Performance:marker in desktop src. Consider shortening it or removing it to keep the render markup clean and consistent with surrounding style. -
Result: REQUEST_CHANGES
-
Reason: unresolved human review thread(s) were present before approval.
-
Head SHA:
225fd046f30154332e6a19f5b1efd9a39e563ac0 -
Workflow run: 28489682405
-
Workflow attempt: 1
Changed-File Evidence Map
flowchart LR
PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
Evidence --> S1["Changed file (3 files)"]
S1 --> I1["repository behavior"]
I1 --> R1["Review risk: Changed file (3 files)"]
R1 --> V1["required checks"]
There was a problem hiding this comment.
Pull request overview
OpenCode reviewed the current-head evidence but found unresolved reviewer or review-agent threads before approval.
Findings
1. HIGH .github/workflows/opencode-review.yml:1 - Unresolved reviewer thread blocks automated approval
- Problem: OpenCode reached an APPROVE control result, but the approval step found unresolved, non-outdated human or review-agent thread evidence on the current pull request.
- Root cause: Reviewer and review-agent feedback can arrive after bounded model evidence is prepared, so the approval step must re-query GitHub immediately before publishing an approval.
- Fix: Address or resolve the listed reviewer thread(s), then re-run OpenCode on the current head.
- Regression test: Keep the approval gate querying reviewThreads(first: 100) after model output and before create_pull_review APPROVE, including bot review agents other than OpenCode itself.
Review thread evidence
Latest unresolved reviewer thread evidence
apps/desktop/src/features/workspace/Workspace.tsx line 99
-
Latest reviewer comment: @copilot-pull-request-reviewer at 2026-07-01T02:40:07Z
-
Comment URL: #496 (comment)
-
Comment excerpt: Inline JSX performance comment is unusually long and (based on a repo-wide search) this is the only '/* Performance:' marker in desktop src. Consider shortening it or removing it to keep the render markup clean and consistent with surrounding style.
-
Result: REQUEST_CHANGES
-
Reason: unresolved reviewer or review-agent thread(s) were present before approval.
-
Head SHA:
556dba7dc08f73f483f66d8fdcf036c162cc0ee3 -
Workflow run: 28510810986
-
Workflow attempt: 1
Changed-File Evidence Map
flowchart LR
PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
Evidence --> S1["Changed file (3 files)"]
S1 --> I1["repository behavior"]
I1 --> R1["Review risk: Changed file (3 files)"]
R1 --> V1["required checks"]
Understood. Acknowledging that this work is now superseded by #367 and stopping work on this task. |
💡 What: JSX 렌더링 시 데코레이션 요소를 생성하기 위해 사용하던
Array.from({ length: X }).map(fn)호출을Array.from({ length: X }, fn)형식으로 수정했습니다. (App.tsx,Workspace.tsx)🎯 Why:
Array.from(...).map()패턴은undefined값으로 채워진 불필요한 중간 배열을 메모리에 할당하고 이를 다시 순회하여 새로운 배열을 만듭니다. 반면,Array.from의 내장 매핑 함수 인자를 사용하면 올바른 크기의 배열을 한 번만 할당하여 인라인으로 처리하므로 메모리 사용량과 가비지 컬렉션(GC) 부하를 줄일 수 있습니다.📊 Impact: 렌더링 사이클 중 불필요한 중간 배열 객체 생성을 방지하여 애플리케이션의 메모리 효율성을 약간 향상시킵니다.
🔬 Measurement:
vitest테스트 스위트가 모두 통과하는 것을 확인하여 UI나 기능에 변경이 없음을 검증했습니다. 성능 향상은 Node.js 성능 측정 스크립트를 통해Array.from()의 매핑 인자가 체이닝 방식보다 빠른 것을 확인했습니다.PR created automatically by Jules for task 10769338844031432113 started by @seonghobae