大表中的角性能策略? [英] Strategies for Angular Performance in Large Table?

问题描述

我正在一个使用AngularJS v1.5.11显示大数据表的项目中-它是一个连续的构建系统，它为源代码控制中出现的每个更改显示一个行表.这些列是一些静态"数据，例如有关更改的信息，而一些动态列则显示该更改的各种自动化构建器/测试器的当前状态.该页面从构建服务器中轮询几个不同的REST端点，并使用来自许多不同构建计算机的最新结果来更新页面.

I'm working on a project that's using AngularJS v1.5.11 to display a large table of data -- it is a continuous build system which displays a table of rows for each change that comes in to source control. The columns are some data that's "static" like the information about the change, and some dynamic columns which show the current state of various automated builders/testers for that change. The page polls several different REST endpoints from a build server, and updates the page with current results from many different build machines.

我已经对该页面进行了相当多的改进以添加其他信息，现在由于观察者过多，我遇到了性能问题.全页摘要经常发生，并且观察者的数量成千上万，导致某些交互操作需要几秒钟的延迟.

I have made quite a few improvements to the page to add additional information, now I'm running in to performance issues due to too many watchers. Full-page digests happen frequently and the number of watchers is in the thousands, causing some interactive operations to have several seconds of delay.

我已经在适用的地方使用了::(一次性绑定")语法，但是观察者最常使用的是显示构建/测试结果的列，并且需要在输入新数据时进行更新的列在这种情况下，一次性绑定没有意义.

I use the :: ("one-time-binding") syntax already where applicable, but the heaviest use of watchers is in the columns which show the build/test results and those need to update as new data comes in. One-time-binding doesn't make sense in those cases.

我已经想出了一个解决方案，其中涉及禁用旧行上的观察程序，因为在特定点之后，我们可以猜测特定行将不再更新(一旦所有构建器都移至处理最近的更改).我使用的是类似于此页面的内容，具有suspendable指令，该指令可以在发生事件时将观察者从一行中移除.

I have already come up with a solution which involves disabling the watchers on old rows, since after a certain point we can guess that a particular row is not going to go get updated anymore (once all of the builders have moved on to processing a more recent change). I'm using something similar to this page, having a suspendable directive which can remove the watchers from a row upon an event.

暂停观看者的方法存在一些问题

There are a couple problems I'm having with the approach of suspending watchers

1. 有时候，那些旧行的确会获得新数据，这与我们停用行的启发式方法相反，例如有人回过头来，然后根据旧更改手动重新运行构建.那么该行将无法显示最新数据
2. 有些交互式"ng-click"功能无法在已停用的行上使用.

我遇到的另一个问题是，当前表仅限于有限的行数，但是我希望它在用户向下滚动(无限滚动")时自动添加行，以便他们可以查看旧的数据.这将大大增加行数，从而增加观察者的性能问题.

The other issue that I have is that currently the table is restricted to a limited number of rows, but I would like for it to automatically add rows when the user scrolls down ("infinite scrolling") so that they can view old data. This is going to dramatically increase the number of rows and thereby increase my performance issues with watchers.

我的问题:

1. 除了我正在做的事情之外，还有其他性能策略对您有帮助吗(一次绑定和禁用观察者)?

1. Are there any other performance strategies that would help other than what I'm doing (one-time-binding and disabling watchers)?

其他人如何在Angular中解决此类问题，或者Angular真的不是非常适合这种高密度信息显示吗? (以前使用jQuery进行类似页面的实现的速度要快得多，因为一旦添加一行，它就几乎不理会了，它就位于DOM中，而每次输入新数据时都不会产生任何额外费用)

How do others approach problems like this in Angular, or is Angular just not really well suited to this kind of a high-density information display? (A previous implementation of a similar page using jQuery runs much faster because once it adds a row, it pretty much leaves it alone, it just sits there in the DOM not incurring any extra cost each time new data comes in)

我意识到我使用的是Angular的旧版本，并且Angular2的性能应该更好.较新版本中的哪些特定功能可能有助于解决这些问题?

I realize I'm on an old version of Angular, and that Angular2 is supposed to be better for performance. What are the specific features in newer versions that might help with these issues?

推荐答案

在没有代码或示例的情况下很难给出有针对性的答案，但以下一些建议可能会对您有所帮助

It's hard to give directed answers without code or examples but here's some suggestions that may help you out

1. 运行 NgStats ，然后查看您的观察者计数以及摘要循环的速度.这将帮助您集中精力.
2. 一次绑定是个好主意.如果您仍然发现与此相关的性能问题，请查看您的ng-repeat代码.
3. 使用track by
改善ng-repeat
4. 确保您永远不会绑定到函数，例如ng-repeat="$ctrl.mySortedData()"或<div>{{$ctrl.getTitle()}}</div>，因为它会使摘要循环变慢.
5. 有趣的是，一些开发人员认为ng-bind的性能要比处理条更好.
6. 如果还没有，请转到与Angular组件绑定的一种方式，它将为您提供帮助
7. 这有点蛮力，但是我发现它有时会有所帮助:注释掉页面的各个部分，以查看哪些特定部分导致了最慢的速度(请参阅#1).一旦确定了这些区域，就可以集中精力在那里.
8. 减少观察者数量是提高绩效的关键.它可以像使用ng-switch一样简单，而不是3 ng-ifs.
9. 与Angular不相关，但是表本身在浏览器中呈现速度较慢，如果可能的话，请考虑移至div + css样式的显示.

1. Run NgStats and look at your watcher count and how fast your digest loops take. This will help focus your efforts.
2. One time binding is a good idea. If you are still seeing performance problems with this I'd look at your ng-repeat code.
3. Improve ng-repeat by using track by
4. Ensure you never bind to a function i.e. ng-repeat="$ctrl.mySortedData()" or <div>{{$ctrl.getTitle()}}</div> as it makes digest cycles slower.
5. Anecdotally some developers see ng-bind perform better than handle bars
6. If you are not already, move to one way binding with Angular components, it'll help
7. It's a bit of a brute force method but I find it helps sometimes: Comment out sections of your page to see what specific sections cause the most slow down (refer to #1). Once you have identified these regions you can focus your time there.
8. Reducing the number of watchers is key to performance. It can be as simple as using a ng-switch rather than 3 ng-ifs.
9. Not Angular related, but Tables themselves are slow to render by the browser, if possible consider moving to a div + css styled display.

使用上述方法，我个人可以渲染数千个屏幕元素，而性能不会出现任何明显下降.我从来没有暂停观察者的声音，听起来像是很难维护的东西.我个人不建议这样做.

Personally I am able to render thousands of on screen elements without any noticeable drop in performance using the methods above. I have never had to suspend watchers and sounds like something that is difficult to maintain. I personally wouldn't recommend that.

这篇关于大表中的角性能策略?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！