langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Severe Performance Degradation with Workflows Exceeding 200 Nodes/Edges #20684

New Issue
Closed
opened 2026-02-21 20:08:28 -05:00 by yindo · 4 comments
yindo commented 2026-02-21 20:08:28 -05:00
Owner
Copy Link
Copy Source

Originally created by @hibean2006 on GitHub (Nov 29, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.10.0

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

When my workflow contains more than 200 nodes and 200 edges, the browser becomes extremely laggy. The browser's task manager shows sustained CPU usage exceeding 100%, indicating a performance bottleneck

✔️ Expected Behavior

Smooth interaction with workflows at this scale (200+ elements), with reasonable CPU utilization (<50% for basic operations).

❌ Actual Behavior

10 second freezes during graph manipulation

Originally created by @hibean2006 on GitHub (Nov 29, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.10.0 ### Cloud or Self Hosted Self Hosted (Source) ### Steps to reproduce When my workflow contains more than 200 nodes and 200 edges, the browser becomes extremely laggy. The browser's task manager shows sustained CPU usage exceeding 100%, indicating a performance bottleneck ### ✔️ Expected Behavior Smooth interaction with workflows at this scale (200+ elements), with reasonable CPU utilization (<50% for basic operations). ### ❌ Actual Behavior 10 second freezes during graph manipulation
yindo closed this issue 2026-02-21 20:08:28 -05:00
yindo commented 2026-02-21 20:08:28 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 29, 2025):

Hi @hibean2006! I'm Dosu and I’m helping the dify team.

This performance issue with workflows over 200 nodes/edges is a known limitation tracked in issue #28931 and also described in #1542. Dify uses React and React Flow for workflow visualization, with custom node and edge rendering and extensive use of hooks and Immer for state updates. These architectural choices, especially SVG edge rendering and frequent immutable state updates, can cause high CPU usage and UI freezes at this scale, as you've observed.

A recent PR improved pan and scroll behavior but did not address the core rendering or state management bottlenecks for large graphs. No fundamental fix or official workaround is available yet. For now, you might try profiling with browser dev tools to identify the most expensive operations, and consider limiting the number of simultaneously visible nodes/edges if possible. If you need to work with very large workflows, you may want to follow React Flow's performance recommendations or look into batching state updates and minimizing unnecessary re-renders in custom hooks and components.

References:

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 29, 2025): <!-- Greeting --> Hi @hibean2006! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> This performance issue with workflows over 200 nodes/edges is a known limitation tracked in issue #28931 and also described in #1542. Dify uses React and React Flow for workflow visualization, with custom node and edge rendering and extensive use of hooks and Immer for state updates. These architectural choices, especially SVG edge rendering and frequent immutable state updates, can cause high CPU usage and UI freezes at this scale, as you've observed. A recent PR improved pan and scroll behavior but did not address the core rendering or state management bottlenecks for large graphs. No fundamental fix or official workaround is available yet. For now, you might try profiling with browser dev tools to identify the most expensive operations, and consider limiting the number of simultaneously visible nodes/edges if possible. If you need to work with very large workflows, you may want to follow React Flow's performance recommendations or look into batching state updates and minimizing unnecessary re-renders in custom hooks and components. References: - [Workflow component using React Flow and custom hooks](https://github.com/langgenius/dify/blob/ddad2460f3ee4906df6819c48babaeab62221b43/web/app/components/workflow/index.tsx#L16-L451) - [Custom edge rendering and SVG complexity](https://github.com/langgenius/dify/blob/ddad2460f3ee4906df6819c48babaeab62221b43/web/app/components/workflow/custom-edge.tsx#L1-L171) - [Node/edge state management and interactions](https://github.com/langgenius/dify/blob/ddad2460f3ee4906df6819c48babaeab62221b43/web/app/components/workflow/hooks/use-nodes-interactions.ts#L6-L2026) - [Recent pan/scroll optimization PR](https://github.com/langgenius/dify/pull/28250) <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/2dea3d23-1c79-48d1-ac99-2b09b099f180?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/2dea3d23-1c79-48d1-ac99-2b09b099f180?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/2dea3d23-1c79-48d1-ac99-2b09b099f180?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/2dea3d23-1c79-48d1-ac99-2b09b099f180?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/2dea3d23-1c79-48d1-ac99-2b09b099f180?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/2dea3d23-1c79-48d1-ac99-2b09b099f180?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/2dea3d23-1c79-48d1-ac99-2b09b099f180?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20performance%20issue%20with%20workflows%20over%20200%20nodes/edges%20is%20a%20known%20limitation%20tracked%20in%20issue%20%2328931%20and%20also%20described%20in%20%231542.%20Dify%20uses%20React%20and%20React%20Flow%20for%20workflow%20visualization%2C%20with%20custom%20node%20and%20edge%20rendering%20and%20extensive%20use%20of%20hooks%20and%20Immer%20for%20state%20updates.%20These%20architectural%20choices%2C%20especially%20SVG%20edge%20rendering%20and%20frequent%20immutable%20state%20updates%2C%20can%20cause%20high%20CPU%20usage%20and%20UI%20freezes%20at%20this%20scale%2C%20as%20you%27ve%20observed.%20%0A%0AA%20recent%20PR%20improved%20pan%20and%20scroll%20behavior%20but%20did%20not%20address%20the%20core%20rendering%20or%20state%20management%20bottlenecks%20for%20large%20graphs.%20No%20fundamental%20fix%20or%20official%20workaround%20is%20available%20yet.%20For%20now%2C%20you%20might%20try%20profiling%20with%20browser%20dev%20tools%20to%20identify%20the%20most%20expensive%20operations%2C%20and%20consider%20limiting%20the%20number%20of%20simultaneously%20visible%20nodes/edges%20if%20possible.%20If%20you%20need%20to%20work%20with%20very%20large%20workflows%2C%20you%20may%20want%20to%20follow%20React%20Flow%27s%20performance%20recommendations%20or%20look%20into%20batching%20state%20updates%20and%20minimizing%20unnecessary%20re-renders%20in%20custom%20hooks%20and%20components.%0A%0AReferences%3A%0A-%20%5BWorkflow%20component%20using%20React%20Flow%20and%20custom%20hooks%5D%28https%3A//github.com/langgenius/dify/blob/ddad2460f3ee4906df6819c48babaeab62221b43/web/app/components/workflow/index.tsx%23L16-L451%29%0A-%20%5BCustom%20edge%20rendering%20and%20SVG%20complexity%5D%28https%3A//github.com/langgenius/dify/blob/ddad2460f3ee4906df6819c48babaeab62221b43/web/app/components/workflow/custom-edge.tsx%23L1-L171%29%0A-%20%5BNode/edge%20state%20management%20and%20interactions%5D%28https%3A//github.com/langgenius/dify/blob/ddad2460f3ee4906df6819c48babaeab62221b43/web/app/components/workflow/hooks/use-nodes-interactions.ts%23L6-L2026%29%0A-%20%5BRecent%20pan/scroll%20optimization%20PR%5D%28https%3A//github.com/langgenius/dify/pull/28250%29)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/28931)
yindo commented 2026-02-21 20:08:28 -05:00
Author
Owner
Copy Link
Copy Source

@hibean2006 commented on GitHub (Nov 29, 2025):

The performance regression occurred after upgrading from version 1.6.0 to 1.10.0. Through self-investigation, I suspect the bottleneck occurs during NodeControl rendering.

A significant improvement was observed when I modified useChecklist in /web/app/components/workflow/hooks/use-checklist.ts to:

export const useChecklist = (nodes: Node[], edges: Edge[]) => { return [] }
@hibean2006 commented on GitHub (Nov 29, 2025): The performance regression occurred after upgrading from version 1.6.0 to 1.10.0. Through self-investigation, I suspect the bottleneck occurs during NodeControl rendering. A significant improvement was observed when I modified useChecklist in /web/app/components/workflow/hooks/use-checklist.ts to: ``` export const useChecklist = (nodes: Node[], edges: Edge[]) => { return [] } ```
yindo commented 2026-02-21 20:08:28 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 29, 2025):

Your finding makes sense: the current useChecklist hook in v1.10.0 performs a lot of per-node validation, variable checks, and data lookups for every render, pulling in many external data sources and running multiple loops and conditional checks over all nodes and edges. This logic is wrapped in a useMemo, but the dependency array is large, so it recomputes frequently as you interact with the graph. With 200+ nodes, this becomes a major bottleneck and explains the high CPU usage and UI freezes. Returning an empty array disables all these checks, which is why you see a big performance boost, but it also means you lose all workflow validation features. For reference, see the current implementation here.

If you need both performance and validation, you might consider profiling which parts of useChecklist are most expensive, batching or throttling validations, or making checklist computation asynchronous for large graphs. Selectively disabling some checks for large workflows could also help.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 29, 2025): <!-- Answer --> Your finding makes sense: the current useChecklist hook in v1.10.0 performs a lot of per-node validation, variable checks, and data lookups for every render, pulling in many external data sources and running multiple loops and conditional checks over all nodes and edges. This logic is wrapped in a useMemo, but the dependency array is large, so it recomputes frequently as you interact with the graph. With 200+ nodes, this becomes a major bottleneck and explains the high CPU usage and UI freezes. Returning an empty array disables all these checks, which is why you see a big performance boost, but it also means you lose all workflow validation features. For reference, see the current implementation [here](https://github.com/langgenius/dify/blob/95528ad8e54fd396be58ccf6ef3a90236d028877/web/app/components/workflow/hooks/use-checklist.ts#L78-L235). If you need both performance and validation, you might consider profiling which parts of useChecklist are most expensive, batching or throttling validations, or making checklist computation asynchronous for large graphs. Selectively disabling some checks for large workflows could also help. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/7aacfe18-4502-48a2-a37b-a2a99328310b?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/7aacfe18-4502-48a2-a37b-a2a99328310b?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/7aacfe18-4502-48a2-a37b-a2a99328310b?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/7aacfe18-4502-48a2-a37b-a2a99328310b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/7aacfe18-4502-48a2-a37b-a2a99328310b?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/7aacfe18-4502-48a2-a37b-a2a99328310b?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/7aacfe18-4502-48a2-a37b-a2a99328310b?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=Your%20finding%20makes%20sense%3A%20the%20current%20useChecklist%20hook%20in%20v1.10.0%20performs%20a%20lot%20of%20per-node%20validation%2C%20variable%20checks%2C%20and%20data%20lookups%20for%20every%20render%2C%20pulling%20in%20many%20external%20data%20sources%20and%20running%20multiple%20loops%20and%20conditional%20checks%20over%20all%20nodes%20and%20edges.%20This%20logic%20is%20wrapped%20in%20a%20useMemo%2C%20but%20the%20dependency%20array%20is%20large%2C%20so%20it%20recomputes%20frequently%20as%20you%20interact%20with%20the%20graph.%20With%20200%2B%20nodes%2C%20this%20becomes%20a%20major%20bottleneck%20and%20explains%20the%20high%20CPU%20usage%20and%20UI%20freezes.%20Returning%20an%20empty%20array%20disables%20all%20these%20checks%2C%20which%20is%20why%20you%20see%20a%20big%20performance%20boost%2C%20but%20it%20also%20means%20you%20lose%20all%20workflow%20validation%20features.%20For%20reference%2C%20see%20the%20current%20implementation%20%5Bhere%5D%28https%3A//github.com/langgenius/dify/blob/95528ad8e54fd396be58ccf6ef3a90236d028877/web/app/components/workflow/hooks/use-checklist.ts%23L78-L235%29.%0A%0AIf%20you%20need%20both%20performance%20and%20validation%2C%20you%20might%20consider%20profiling%20which%20parts%20of%20useChecklist%20are%20most%20expensive%2C%20batching%20or%20throttling%20validations%2C%20or%20making%20checklist%20computation%20asynchronous%20for%20large%20graphs.%20Selectively%20disabling%20some%20checks%20for%20large%20workflows%20could%20also%20help.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/28931)
yindo commented 2026-02-21 20:08:28 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Nov 29, 2025):

Duplicated, please upgrade to v1.10.1

@crazywoola commented on GitHub (Nov 29, 2025): Duplicated, please upgrade to v1.10.1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#20684
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?