JS网格性能比较

Question

我使用angular-ui-grid(http://ui-grid.info/)来显示表格数据.总的来说,它很慢,所以我们决定使用ag-grid(https://www.ag-grid.com/).这对于常规大小的数据集来说,性能更高,更好.

但是,现在我们正在处理一些大小为100列×10,000行(~1M单元)的表格数据,并且网格的性能似乎相当慢.

我想知道是否有人使用过hypergrid(https://fin-hypergrid.github.io/core/2.0.2/) - 它似乎'解决'大cols x 大行的问题,在他们的演示中似乎在大型数据集上更快(几乎一个数量级).

hypergrid如何与ag-grid相比,或者对大数据大小的性能进行反应虚拟化？

Answer 1

我没有尝试过你提到的那些示例库,但也许我可以解释为什么fin-hypergrid最突出.我的观点主要基于我的JavaScript知识以及这种东西如何在后面工作.

我也许应该开始react-virtualized和ag-grid:

两者都使用填充DOM的方式,只显示视图的一部分数据,动态地从DOM中删除不再可见的内容,并提前添加即将发布的内容.现在问题在于添加和删除DOM中的内容,因为这样可以非常快/多次执行.因此,我们会遇到一些滞后或抖动.您可以实际检查Web控制台>配置文件>记录JavaScript CPU配置文件,并看到此方法需要一些时间才能完成.因此,从不同的唯一事情react-virtualized,并ag-grid为他们的应用在尽可能平稳的方式这些变化的算法.

ag-grid从我所看到的,是受这个问题影响最大的那个,因为你实际上可以看到一些尚未完成渲染的元素,并且当你滚动太快时会遇到严重的延迟.

react-virtualized另一方面,以最流畅的方式实现其算法的出色工作.这可能是DOM操作类别中可用的最佳库,尽管它仍然存在操作DOM太快而产生延迟的问题,尽管只有在涉及大块数据时才会出现这种情况.

以下是fin-hypergrid擅长的原因:

现在这并不意味着hypergrid一切都很好,它也有一些缺点:

现在总结一下,我可能建议使用,react-virtualized因为它提供了最流畅的卷轴,上面fin-hypergrid.如果你愿意忽视它的缺点fin-hypergrid,那么这fin-hypergrid是最好的选择.

更新:

自从我们讨论了JS/CSS,这些表的canvas实现.虽然这个人是不是主要是JS表库,但在一个框架,我应该提到的最后一个可能的竞争者Google Sheets可能已经使用它被称为d3.js.

d3.js这次讨论的唯一缺点是:

如果你想要使用CSS样式功能的Canvas速度,那么d3.js问题就是学习它的关键.

Answer 2

我经历了不同的数据网格选项。然后我发现了这个。

希望此答案对正在数据网格之间进行性能比较的任何人有所帮助。

即使在您阅读完我提供的文章后，这里也要注意的几点。

1-一旦一个网格“足够快”，这意味着渲染滞后不明显，那么哪个网格比下一个网格快都没有关系。

2-基于画布的网格不是HTML网格-您无法使用HTML对其进行自定义。网格将很难由标准JavaScript / CSS开发人员设置样式/主题/自定义。

选择您的毒药，因为它不仅涉及消费者方面的表现。

我十分同意。我们在所有基于画布和基于Dom的HTML5 DataGrid的顶部都生成了Adaptable Blotter。而且我们总是发现现实生活中实际上并不需要性能要求（因为大多数时候他们实际上并没有250,000行每秒更新250次），而通过使用画布提高性能，最终会给用户带来较差的用户体验对于他们每天实际做的事情-样式，排序，过滤，编辑等。性能固然重要，但要切合实际。 (2认同)
恰到好处！它实际上是基于您最想要的应用程序。如果渲染速度不明显，并且您还可以进行样式设置，则也添加dom对象，然后添加我认为最好的对象，就像您所说的那样。 (2认同)
是的实际上恕我直言，它比这简单。每年我们进行数百个演示，因此我们看到很多网格和网格设置，我想说95％的时间明确表示他们需要DOM，而不是画布网格。实际上，ag-Grid已经成为市场上最好的HTML5 DataGrid，而他们所需要的基于Dom的DataGrid 95％的时间就是ag-Grid。我不记得上一次我们建议客户使用ag-Grid以外的其他方法，ag-Grid是其市场领导者，这是有原因的。 (2认同)