[Bug] setOption took a long time. And block UI process.

[jianqi-jin]

Version

5.3.3

Link to Minimal Reproduction

No response

Steps to Reproduce

setOption took a long time.
I think maybe there are some diff process need to take some time. So, is there any way to send these merge processes to a worker?

Current Behavior

setOption took maybe 30ms. And block the UI process.

Expected Behavior

setOption don't block the UI process.

Environment

- OS:
- Browser:
- Framework:

Any additional comments?

No response

[Ovilia]

30ms is acceptable time and should not be noticable to users. Do you call setOption very frequently or what else cause the problem? You may provide a demo to show the case.

[echarts-bot]

@JinJianQi Please provide a demo for the issue either with Official Editor, CodePen, CodeSandbox or JSFiddle.

[jianqi-jin]

@Ovilia Hi~

I find that when the value have a big object, the setOption will take longer time.

This is an Online demo to reproduce.

https://codesandbox.io/s/confident-shockley-2t1e7n?file=/src/index.js

There is about 1000 x 50 values. And each item has a large rawData(it's a json object).

Something like this:

{
itemStyle: {},
value: [0, 10, 20, {...bigObject}]
}

Through the Performance tab of ChromeDevTool, I find the clone method of setOption take a long time. Like this:

I think there must be some deepClone processes? Is there any way not to clone ?

[jianqi-jin]

30ms is acceptable time and should not be noticable to users. Do you call setOption very frequently or what else cause the problem? You may provide a demo to show the case.

@Ovilia

In my case, I have a treeShake function. I would call this function when every time the dataZoom changed. I just cut off items out of window through treeShake. So, this function will be called frequently.

[github-actions]

This issue has been automatically marked as stale because it did not have recent activity. It will be closed in 7 days if no further activity occurs. If you wish not to mark it as stale, please leave a comment in this issue.

[nantunes]

#17656 was also closed.

The open question is: is there a reason to clone?

I'm working with Apache Arrow data. Apache Arrow is a portable format for storing column-oriented data, allowing data to be shared as-is between various systems and language runtimes. It enables zero-copy query processing over large amounts of loaded data.

I'm trying to avoid pre-processing the data. I'm not expecting echarts to support arrow tables, but I'm able to use object proxies that translate between the two. But in the end everything is getting cloned, affecting both performance and memory.

zrender's clone function states "Instance of user defined class will be cloned to a plain object, without properties in prototype.". There is also no way to customise BUILTIN_OBJECT.

[MindFreeze]

If you have a lot of charts on a page and they all update at the same time, it blocks for ~1s sometimes. Even if nothing is updated, just calling chart.setOption({}) blocks the UI. lazyUpdate doesn't help either

[MindFreeze]

clone doesn't take that much time in my case but I found another major issue.
The chart rerenders fully for every setOption call. So even if you just want to enable dataZoom, change the tooltip formatter or even with just setOption({}), you get a full render. This can block the main thread for a long time when there is a lot of data.
This can be somewhat mitigated by checking the new options and skipping render in some cases.
Another improvement would be async rendering where echarts releases the main thread (with setTimeout, for example) during long renders. A setTimeout between rendering each series would be the most simple approach. Chunking all the data would be more comprehensive.