[Bug] Echart setoption内存会随时间增长且无法回收（必现）

[idealy233]

Version

5.5.1

Link to Minimal Reproduction

https://echarts.apache.org/examples/zh/editor.html?c=doc-example%2Ftutorial-dynamic-data

Steps to Reproduce

这是贵官网文档的示例，复现步骤如下
1、将该网址使用chrome浏览器访问
2、打开开发者工具，打开内存tab页面
3、在几分钟的时间周期内点击录制按钮
4、观察每个快照的内存情况
此时可以发现内存会一直在增大，且无法清除。

Current Behavior

该内存在三分钟的时间内涨了1MB，而且这是数据量小且只有一个图表的情况，如果是多个图表或者增加数据量（data），那么内存增加的会更加明显。

如上所述，如果链接不可用，这边还可以提供代码。

Expected Behavior

在业务使用过程中，多次调用setoption不应存在内存上涨且无法降低的情况。

Environment

- OS:Windows 11
- Browser:Chrome
- Framework:Vue@3

Any additional comments?

业务中不可以clear图表（会造成数据显示错误），此时在多次动态更新数据图表后（时间较长时）页面必定崩溃

[echarts-bot]

@idealy233 It seems you are not using English, I've helped translate the content automatically. To make your issue understood by more people and get helped, we'd like to suggest using English next time. 🤗

TRANSLATED

TITLE

[Bug] Echarts Memory Overflow Issue (Must Appear)

BODY

Version

e.g.

Link to Minimal Reproduction

https://echarts.apache.org/examples/zh/editor.html?c=doc-example%2Ftutorial-dynamic-data

Steps to Reproduce

This is an example of your official website document. The steps to reproduce are as follows:

1. Access this URL using chrome browser
2. Open the developer tools and open the memory tab page.
3. Click the record button within a few minutes
4. Observe the memory status of each snapshot
   At this time, you can find that the memory will keep increasing and cannot be cleared.
   

Current Behavior

The memory increased by 1MB in three minutes, and this is a case where the data volume is small and there is only one chart. If there are multiple charts or the amount of data (data) is increased, the memory increase will be more obvious.

As mentioned above, if the link is not available, the code is also provided here.

Expected Behavior

During business use, calling setoption multiple times should not cause the memory to increase and cannot be reduced.

Environment

- OS: Windows 11
- Browser:Chrome
- Framework:Vue@3

Any additional comments?

Charts cannot be cleared in business (it will cause data display errors). At this time, the page will definitely crash after dynamically updating the data chart multiple times (when the time is long).

[plainheart]

用浏览器无痕模式（即不加载任何扩展插件等）测试一下看看，对比下结果。

[idealy233]

用浏览器无痕模式（即不加载任何扩展插件等）测试一下看看，对比下结果。

chrome的无痕模式运行5分钟四次快照结果 中间每次都点击回收垃圾
结果还是内存会有增长，问题依然可以复现

[helgasoft]

Measuring usedJSHeapSize usually gives a good idea about memory leaks, see #19984.
Adding the same code here:

cnt=0;
setInterval(function () {
    if (cnt++ % 20 ==0) console.log(performance.memory.usedJSHeapSize);
   ...}, 500)

produces the following numbers:

34088105, 26805145, 32471229, 28301814 31722715, 34552112, 29943652, 32546547, 32307095, 29559186, 29551095, 29960710, 30817662, 27309092, 25565771, 31258954, 28833919, ...

which do not show evidence of a memory leak.

[idealy233]

Measuring usedJSHeapSize usually gives a good idea about memory leaks, see #19984.测量 usedJSHeapSize 通常可以很好地了解内存泄漏，请参见 #19984 。 Adding the same code here:在此处添加相同的代码：

cnt=0;
setInterval(function () {
    if (cnt++ % 20 ==0) console.log(performance.memory.usedJSHeapSize);
   ...}, 500)

produces the following numbers:生成以下数字：

34088105, 26805145, 32471229, 28301814 31722715, 34552112, 29943652, 32546547, 32307095, 29559186, 29551095, 29960710, 30817662, 27309092, 25565771, 31258954, 28833919, ...

which do not show evidence of a memory leak.没有显示内存泄漏的证据。

1、usedJSHeapSize获取内存方式有效的情况下：
需要注意的是这个内存溢出的问题在数据量小时并不明显，在您的回复的例子中是每10秒进行一次的内存检查，这样获取的数据您是否试过长时间获取呢？比如1个小时或者更长时间，当然也可以在例子中增加数据量的显示来减少测试的时间（比如增加x轴显示的数据量），这样将能更明显的看出内存的变化。
2、usedJSHeapSize在该情况下判断内存泄露的有效性存疑？
usedJSHeapSize值只能代表该时刻的内存使用情况，并不能完全反映出整体的内存管理的具体状况。例如存在内存回收机制会造成该值波动，较短时间的检测该值是否无助于监测不明显的内存泄漏问题？
3、【重要】为什么chrome浏览器的无痕模式，运行该示例时内存会随时间增长且无法消除？
这个问题是如何导致的？是chrome浏览器的问题，还是代码的问题？是否可以就此问题给予一定解释
（同时我稍后将在edge和firefox的浏览器验证是否可以复现该问题）

[idealy233]

经过测试 edge上和chrome问题一样。
firefox内存管理中内存上涨不太明显，正进一步测试。

发现一个情况，看看对分析是否有意义：
1、开发环境是vue3
2、对比官方例子中内存溢出的比较，自己的代码明显溢出速度更快，而且分布在array内存的溢出更多（而官方例子比较均匀且complied code溢出占用多）
3、确认了，只注释掉setoption这一行代码后 内存一点都不会溢出（可以排除本身代码问题）
4、下图中我现在的时间是10点50分了，而10点40分的信息还未释放，我的图表只显示1分钟的信息，这个信息还未释放是否可以借此来分析溢出原因？

[plainheart]

开发环境是vue3

是不是把整个 data 深度监听了？用了 ref 或者 reactive？chart 实例对象用 ref 声明了？尽量用纯 JS 去测试。

运行一段时间后，内存有所小的增长是正常的，因为内部会缓存一些东西。

[idealy233]

是不是把整个 data 深度监听了？

data之前确实是深度监听，所以怀疑是这个问题已经调整和官方案例相同了，换为了setInterval，结果还是比较快的涨内存

用了 ref 或者 reactive？

因为是vue子页面的缘故 prop的data确实用了reactive，这边尝试改一下再看

chart 实例对象用 ref 声明了？

chart实例用的let声明的没有用ref

运行一段时间后，内存有所小的增长是正常的，因为内部会缓存一些东西。

嗯嗯 小的内存增长业务也是接收的 这边调整之后再观察看下

感谢回复！

[idealy233]

已经移除了所有reactive，页面无 ref 和 data 深度监听

依然有很明显的内存增长，且array在其中依然占比很明显

[idealy233]

感觉业务系统的纯js开发在如今不这么现实。
如果内存问题确实是vue3+echarts导致的，是否可以考虑跟踪下vue3等常用框架下使用echarts的导致内存溢出的兼容问题呢？
例如在上述例子中，已经尽可能避免使用watch deep或ref等可能造成内存问题的代码，仍无法有效的避免内存快速增长