Skip to content

⚡ Bolt: [O(1) Map 룩업으로 NetworkGraph 성능 최적화] - #1362

Closed
seonghobae wants to merge 1 commit into
developfrom
bolt-networkgraph-lookup-optimization-7366099968101493112
Closed

⚡ Bolt: [O(1) Map 룩업으로 NetworkGraph 성능 최적화]#1362
seonghobae wants to merge 1 commit into
developfrom
bolt-networkgraph-lookup-optimization-7366099968101493112

Conversation

@seonghobae

Copy link
Copy Markdown
Contributor

💡 What

NetworkGraph 컴포넌트의 관계 요약 및 노드 선택 핸들러(describeEdge, selectNode, selectGraphNode)에서 노드 라벨을 찾을 때 사용하던 Array.prototype.find() 기반의 $O(N)$ 검색을 미리 생성된 nodeMap을 활용한 $O(1)$ Hash Map 검색으로 최적화했습니다.

🎯 Why

기존에는 노드 선택 이벤트를 처리하거나 여러 관계를 순회할 때마다 전체 노드 배열을 처음부터 검색했습니다. 이는 노드 개수가 증가함에 따라 $O(M \times N)$ 수준의 연산 비용을 발생시켜 메인 스레드를 블로킹할 위험이 있었습니다. 최적화를 통해 이 병목을 해소합니다.

📊 Impact

  • 노드 라벨 검색 시간 복잡도를 $O(N)$에서 $O(1)$로 단축.
  • 대량의 노드/간선을 렌더링하고 선택할 때 발생하는 UI 렌더링 블로킹 및 프레임 저하 최소화.
  • 불필요한 배열 순회 연산 제거.

🔬 Measurement

  1. frontend/src/components/NetworkGraph.tsx 파일 내 findNodeLabel 함수가 Map을 사용하도록 올바르게 패치되었는지 확인.
  2. cd frontend && pnpm run test 명령을 통해 유닛 테스트가 정상 통과하는지 확인.

PR created automatically by Jules for task 7366099968101493112 started by @seonghobae

Replaced O(N) Array.prototype.find calls inside describeEdge and
selection handlers with O(1) Map.get lookups to prevent UI freezes
on large datasets.
@google-labs-jules

Copy link
Copy Markdown
Contributor

👋 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 @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

@coderabbitai

coderabbitai Bot commented Aug 15, 2026

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 45 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 15e3ca76-726e-498c-98a7-f4e4fca0b9d3

📥 Commits

Reviewing files that changed from the base of the PR and between bc98789 and ec0e122.

📒 Files selected for processing (2)
  • .jules/bolt.md
  • frontend/src/components/NetworkGraph.tsx

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Copy link
Copy Markdown
Contributor Author

Closing as superseded by #1358 after exact-current-head diff comparison against develop@bc98789521d21271e84789888413c182aa111b4d.

#1358 already implements the two buyer-relevant selection-path O(1) lookups on the same current base and adds a test-first regression covering both graph-event and control-selection handlers; its exact head 61781b70185799f6901c19e092fef36b766aa3db also has the repository Application CI, Bandit, Semgrep, Dependency Review, Security Scan, and container-build workflows green.

The additional findNodeLabel(..., nodeMap?) change here does not add a distinct describeEdge optimization: describeEdge already reads nodeMap directly whenever one is supplied, while its fallback branch necessarily calls the helper with nodeMap undefined. The .jules/bolt.md note is not unique product behavior and is not sufficient reason to keep an overlapping production-code lane open.

Preserving #1358 as the canonical lane avoids competing writes to NetworkGraph.tsx while retaining the tested performance improvement.

@google-labs-jules

Copy link
Copy Markdown
Contributor

Closing as superseded by #1358 after exact-current-head diff comparison against develop@bc98789521d21271e84789888413c182aa111b4d.

#1358 already implements the two buyer-relevant selection-path O(1) lookups on the same current base and adds a test-first regression covering both graph-event and control-selection handlers; its exact head 61781b70185799f6901c19e092fef36b766aa3db also has the repository Application CI, Bandit, Semgrep, Dependency Review, Security Scan, and container-build workflows green.

The additional findNodeLabel(..., nodeMap?) change here does not add a distinct describeEdge optimization: describeEdge already reads nodeMap directly whenever one is supplied, while its fallback branch necessarily calls the helper with nodeMap undefined. The .jules/bolt.md note is not unique product behavior and is not sufficient reason to keep an overlapping production-code lane open.

Preserving #1358 as the canonical lane avoids competing writes to NetworkGraph.tsx while retaining the tested performance improvement.

Understood. Acknowledging that this work is now obsolete and stopping work on this task.

@seonghobae seonghobae closed this Aug 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant