Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: the upsert method in base-shape.js may cause memory leak #6850

Open
3 of 10 tasks
ZTao-z opened this issue Mar 10, 2025 · 2 comments
Open
3 of 10 tasks

[Bug]: the upsert method in base-shape.js may cause memory leak #6850

ZTao-z opened this issue Mar 10, 2025 · 2 comments

Comments

@ZTao-z
Copy link

ZTao-z commented Mar 10, 2025

Describe the bug / 问题描述

Image

base-shape.ts中的upsert函数只关心新增或已存在的shape,如果渲染过程中shape的key值发生变化,已存在于 shapeMap 上的元素无法被清空

Reproduction link / 复现链接

No response

Steps to Reproduce the Bug or Issue / 重现步骤

render() {
  upsert(`key-${Math.random()}`, ..., ...)
}

当每次渲染的shape的className不是相同的,上次渲染的shape就会常驻在shapeMap中,无法被删除和更新

Version / 版本

🆕 5.x

OS / 操作系统

  • macOS
  • Windows
  • Linux
  • Others / 其他

Browser / 浏览器

  • Chrome
  • Edge
  • Firefox
  • Safari (Limited support / 有限支持)
  • IE (Nonsupport / 不支持)
  • Others / 其他
@ZTao-z ZTao-z added the waiting for maintainer Triage or intervention needed from a maintainer. label Mar 10, 2025
Copy link

The issue you've described involves a potential memory leak in the upsert method within base-shape.ts of the antvis/G6 library. The problem arises when the key value of a shape changes during rendering, causing previously existing elements in the shapeMap to remain uncleared.

To address this issue, a possible solution would be to modify the upsert method to ensure that elements in the shapeMap are properly cleared or updated when their keys change. This would prevent old shapes from persisting in memory.

Would you like me to search for any existing solutions or related discussions in the repository? If you need further assistance or want to explore potential code modifications, please let me know!

@zhongyunWan zhongyunWan added refactor performance and removed waiting for maintainer Triage or intervention needed from a maintainer. labels Mar 11, 2025
@zhongyunWan
Copy link
Contributor

zhongyunWan commented Mar 11, 2025

This is a good proposal. We will take two factors into comprehensive consideration:

  1. Whether the usage of the key change of the shape is frequent;
  2. The magnitude of the impact of the refactoring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants