G6 icon indicating copy to clipboard operation
G6 copied to clipboard

想请问一下force布局大概能承载多少个节点的数据,感觉现在渲染几千个节点的数据页面就会卡顿,

Open morLight opened this issue 4 years ago • 7 comments

  • G6 Version:
  • Platform:
  • Mini Showcase(like screenshots):
  • CodePen Link:

morLight avatar Jul 01 '20 09:07 morLight

是自定义节点吗?一个节点上有多少个图形?

渲染性能主要受到画布上总图形个数影响,force 布局每一次迭代都会重绘画布,建议在较大规模的数据量下使用单个最简单图形作作为节点,边也使用最简单的 'line',隐藏文本等其他图形,布局结束后再显示(可监听 afterlayout 时机事件)。

布局性能方面,力导向布局在算法理论上就很难在大规模图数据上有很快的速度,这是由于力导向布局算法每一次迭代的复杂度高且收敛速度较慢。

Yanyan-Wang avatar Jul 01 '20 11:07 Yanyan-Wang

是自定义节点吗?一个节点上有多少个图形?

渲染性能主要受到画布上总图形个数影响,force 布局每一次迭代都会重绘画布,建议在较大规模的数据量下使用单个最简单图形作作为节点,边也使用最简单的 'line',隐藏文本等其他图形,布局结束后再显示(可监听 afterlayout 时机事件)。

布局性能方面,力导向布局在算法理论上就很难在大规模图数据上有很快的速度,这是由于力导向布局算法每一次迭代的复杂度高且收敛速度较慢。

我用的紧凑树布局,每个自定义的rect节点里面还有4-6个shape,大概有500个rect节点。根据您说的,我默认只保留了最简单的节点rect,内部的所有图形我都把visible设为了false, 但是我再beforelayout和afterlayout之间打了console.time并没发现布局时间有所提升。请问是我的隐藏图形的方式有问题吗,怎么证明这种只显示最简单节点的方式可以提升布局性能呢。

daweichendoctor avatar Jul 30 '20 08:07 daweichendoctor

这里要注意区分是渲染性能还是布局性能。

图形数量少可以提升渲染速度(渲染是异步的,简单的 console 时间是看不出来的)。

布局速度与节点数量有关,与图形数量无关。

Yanyan-Wang avatar Aug 04 '20 02:08 Yanyan-Wang

可以参考下文档性能测试案例:https://g6.antv.vision/zh/examples/performance/perf

JohnnyLuv avatar Sep 25 '20 02:09 JohnnyLuv

这里要注意区分是渲染性能还是布局性能。

图形数量少可以提升渲染速度(渲染是异步的,简单的 console 时间是看不出来的)。

布局速度与节点数量有关,与图形数量无关。

请问一下如果想要统计布局的布局时间和渲染时间应该怎么做呢?好像没有看到相关的API函数,简单的console.log时间应该算的是布局时间。

xuyaqist avatar Mar 07 '22 07:03 xuyaqist

我的为什么120个节点200多条线就开始卡了,拖拽画布和拖动节点都很卡

hdong-emiya avatar Mar 22 '22 09:03 hdong-emiya

我也是这样,请问您现在解决这个问题了么

ronghuijun avatar May 11 '22 07:05 ronghuijun

这里要注意区分是渲染性能还是布局性能。 图形数量少可以提升渲染速度(渲染是异步的,简单的 console 时间是看不出来的)。 布局速度与节点数量有关,与图形数量无关。

请问一下如果想要统计布局的布局时间和渲染时间应该怎么做呢?好像没有看到相关的API函数,简单的console.log时间应该算的是布局时间。

不配置 layout,看下渲染出来需要多长时间。

Yanyan-Wang avatar Nov 24 '22 07:11 Yanyan-Wang

我的为什么120个节点200多条线就开始卡了,拖拽画布和拖动节点都很卡

需要看具体的实现方式,如果不是超级复杂的自定义节点,拖拽应该不会出现卡顿。或许你使用了 polyline?在没有指定 controlPoints 的时候将使用 A* 自动巡径算法,这是非常耗时的,特别是拖拽节点的过程中需要频繁地进行重新计算。拖拽画布的卡顿可以通过配置 enableOptimize: true 进行优化,在拖拽过程中仅显示关键图形,避免全图的频繁全量重绘

Yanyan-Wang avatar Nov 24 '22 07:11 Yanyan-Wang

我也是这样,请问您现在解决这个问题了么

可以给下 demo 看看是否有优化空间

Yanyan-Wang avatar Nov 24 '22 07:11 Yanyan-Wang

布局使用 force2 性能有所提升。如果边使用的是 polyline,最新版本也大大提升了性能,欢迎试用。

尊敬的用户,您好。我们很重视您的 issue,但由于长时间没有答复,我们暂时认为这个问题已经解决。如果还有任何问题,请随时根据 issue 模版再开启新的 issue。

Yanyan-Wang avatar Dec 26 '22 07:12 Yanyan-Wang

Hi @Yanyan-Wang , 我有2020个节点,5429条边,还是很卡(看下来的链接)。你觉得哪里还可以提升性能吗? https://codesandbox.io/s/admiring-microservice-4wb97c?file=/index.js

linxingquan avatar Dec 28 '22 07:12 linxingquan

Hi @Yanyan-Wang , 我有2020个节点,5429条边,还是很卡(看下来的链接)。你觉得哪里还可以提升性能吗? https://codesandbox.io/s/admiring-microservice-4wb97c?file=/index.js

我和你遇到相同的问题,请问解决了吗,我的force和force2布局都有很慢,1、2000个节点就很慢了

HogoZhang avatar Jan 10 '24 08:01 HogoZhang

我认为这是Graph Rendering本身的性能限制。我只是通过限制每次显示的节点数量来提升显示速度,因为显示太多的节点人也看不过来。

linxingquan avatar Jan 11 '24 07:01 linxingquan