Angular: Performance optimization / Оптимизация производительности
 

Всем привет

В этой теме хотелось бы обсудить вопрос оптимизации производительности в ангуляре: как правильно писать код; чего следовало бы избегать; рецепты оптимизации производительности и т.п.

---

Ниже выжимка из всей темы

СОВЕТЫ ПО ОПТИМИЗАЦИИ ПРОИЗВОДИТЕЛЬНОСТИ

расширенное объяснение по каждому пункту можно найти почитав тему

1. Если возможно то не слушать объекты и массивы целиком
2. Без крайней нужды не вешать WATCH на функции
3. Не вызывать

   $scope.$apply();
   $scope.$digest();
   

   слишком часто (например, в обработчиках событий scroll или mousemove)
4. Не выводить в
   

   <element ng-repeat="..."></element>
   

   тысячи элементов, а вывести первые элементы и сделать динамическую подгрузку
5. Если элемент скрыт с помощью ng-show или ng-hide
   

   <element ng-show="false"></element>
   <element ng-hide="true"></element>
   

   и внутри него есть тяжелые вычисления, вероятно, имеет смыл использовать [ng-if|ng-switch] чтобы их избежать
6. Использовать синтаксис
   

   <element ng-repeat="item in array track by $index"></element> или
   <element ng-repeat="item in array track by item.id"></element>
   

   вместо
   

   <element ng-repeat="item in array"></element>
   

   чтобы отслеживать изменения по индексу или id, а не по значению
7. Обновлять текущий и вложенные скопы
   

   $scope.$digest();
   

   а не все приложение

   $scope.$apply();
   

Я уже касался частично.

По scope.
1) Если возможно то не слушать объекты и массивы целиком. (так как ангуляру нужно выполнить цикл по всем свойствам)
2) Без крайней нужды не вешать WATCH на функции. (они будут срабатывать при любом изменении scope)
3) Подозреваю что события могут быть быстрее чем watch в ряде ситуаций, но не проверял.


По шаблону.
Мне очень интересно как ведут себя директивы помещенный внутрь ngrepeat. Не получится ли так что каждая директива внутри цикла будет пересоздаваться когда ngrepeat срабатывает повторно. Я полагаю что так оно и есть, а это означает что нужно дважды подумать прежде чем пихать директивы внутрь ngrepeat. Впрочем с несколькими сотнями итераций проблем быть не должно, конечно только если вы не обновляете данные несколько раз в секунду :) А вот на мобиле ХЗ сколько потянет.

Ну и просто философия. :)
Никто нативные операции на дум не отменял, и jQuery пока жив :) Если директива тяжелая по производительности, то никто не обязывает вас использовать шаблоны и связывание. Вы можете просто переписать внутренности директивы на голом JS или jQuery и получить быструю и максимально оптимизированную директиву. Ну к примеру в шаблоне директивы есть ng-show, возможно вы сумеете заменить ее нативным .style.display который однозначно сработает быстрее.

DjDiablo, спасибо.

Еще у меня вот такие мысли ng-if, ng-switсh etc. как способ оптимизации производительности. Что думаете по этому поводу?

думаю, так оно и есть (судя по поведению)

тогда зачем ангуляр использовать? :)

Тест не честный чуточку :). Поместив test() в ngShow ты заставил срабатывать test при любом изменении, но это не означает что срабатывает сам ngShow. Test вызывается только для того чтобы оно вернуло true или false, и ngShow получив это значение мог правильно отработать. Если бы ты слушал свойство а не функцию test то ngShow срабатывал бы только при изменении свойства. NgShowController:Controller:test и NgIfController:Controller:test не должны были оказаться в консоли если бы выводились самим ngShow .

Иными словами в примере не все директивы при публикации срабатывают, срабатывают только функции которые указаны директивам в атрибутах. Даже если нерв ты знаешь это, я для других указываю, так как может неправильный вывод сделать из эксперимента.

Тем не менее ng-if это прикольная тема. Допустим в табах можно попробывать выключать содержимое невидимых закладок или чо нибудь в этом духе.

а у меня честных тестов не бывает :D

или, например, при пагинации на клиенте или любые другие "не нужные" в данный момент куски разметки вместе с кодом

Об очевидном. Еще лучше не делать так:

element.bind( 'mousemove scroll ...', function() {
    $scope.$apply(function() { /* code here */ );
});

не вызывать пересчет скопа каждый раз в событиях, которые срабатывают достаточно часто, а по возможности использовать прокси

Не выводить в ng-repeat тысячи элементов, а сделать динамическую подгрузку и выгрузку первых элементов (как чат вконтакте). Тогда и с оптимизацией директивы можно не париться)

Ограничиваю список через фильтр. Этакий пэджинатор.

app.filter('startFrom', function() {
		return function(input, start) {
			start = parseInt(start);
			return input.slice(start);
		}
	})

И пишу в html:

<button ng-repeat="(n, button) in selectorField.items | startFrom:(currentPage - 1) * limit | limitTo:limit" ng-mousedown="setSelector(n)" ng-bind-html-unsafe="button.title"></button>

Но сотнях не тестировал, но работает шустро. Что думаете?

Надо потестить)

Чуть не забыл. Еще одна фишка для оптимизации.
тыц1 и тыц2.

Суть в том, что вешать события на $rootScope нужно внимательно, т. к. при удалении шаблона с контроллером корневая область видимости никуда не девается и обработчик остается.

nerv_, посмотри в своем загрузчике файлов, кажется у тебя там именно такая ситуация. Т.е. если я закрою страничку загрузки файлов, то все обработчики так и останутся на $rootScope

спасибо. У меня это как раз на стадии обсуждения.

Ознакомился со статьей. Что могу сказать, если речь идет о роутах, то есть события, позволяющие отловить изменения маршрута. Я так уже делал, останавливал setInteral, который крутился на странице. Т.к., если его не остановить, знаешь, что будет :)

С ui-router не работал также как и с angular route segment

А можно просто сделать колбеками, как у меня))

Поработай с ui-router — классная штука. Единственное, что использую от сторонних ангуляр-разработчиков) Почти всю документацию перевел

выпилил :)

Не очень понял смысл:
https://github.com/nervgh/angular-fi...ploader.js#L12
https://github.com/nervgh/angular-fi...ploader.js#L32
Где ты ушел от rootScope?)

Увидел. А почему бы не брать scope из директивы? Чтобы не задавать его в контроллере всякий раз. Я бы, не зная о подвохе с rootScope, всегда бы опускал этот параметр (т.к. смысла он почти не несет) и получал бы его по-умолчанию и все связанные проблемы.

потому, что я при создании экземпляра загрузчика подписываюсь на события определенной области видимости
https://github.com/nervgh/angular-fi...ploader.js#L30

ng-repeat="value in array track by $index"
 

Уже сталкивался с подобным синтаксисом

<div ng-repeat="item in array track by $index">
   ...
</div>

и в очередной раз написав это, решил открыть доку.
В доке вижу
Делаю вывод: это может способствовать улучшению производительности директивы ng-repeat.

---

В довесок
http://docs.angularjs.org/api/ng.directive:ngRepeat

$scope.$digest() instead $scope.$apply()
 

По возможности используйте

$scope.$digest(); 
// вместо
$scope.$apply();

Первый обновляет текущий и вложенные скопы, последний все приложение.

Думаю, в 3 пункт стоит добавить, что стоит использовать throttle или debounce для scroll, mousemove, onkeyup и т.п.

$scope.$digest() можно использовать, если есть уверенность, что изменения были только в рамках текущего скопа.

Только ты напиши, для чего это. Большинство таких слов ругачих не знают :) А я раскрывать секрет не стану :no:

Для фильтров, которые при каждом $digest'е часто возвращают одно и то же значение, полезно использовать memoize. Оно возвращает моментально значение функции, если не поменялся хэш по которому она была вычислена. Эти функции уже встроены в Underscore и Lo-Dash.
В итоге это будет выглядеть примерно так:

app.filter('tel',  [function() {
    return _.memoize(function (tel) {
	if (!tel) return '';
        tel = "("+tel.slice(0, 3)+") "+tel.slice(3, 6)+'-'+tel.slice(-4);
        return tel;
    });
}]);

По поводу вышеописанных "throttle и debounce", они так же встроены в эти библиотеки. Я просто оставлю описание с документации к Underscore:


_.throttle(function, wait) - Вернет версию функции, которая, при повторных вызовах, исполниться не чаще одного раза в заданный промежуток wait. Полезна для использования при обработке событий, которые происходят слишком часто.

var throttled = _.throttle(updatePosition, 100);
$(window).scroll(throttled);

_.debounce(function, wait) - Вернет версию функции, исполнение которой начнется не ранее, чем истечет промежуток wait, после ее последнего вызова. Полезно для реализации логики, которая зависит от завершения действий пользователя. Например, проверить орфографию комментария пользователя лучше будет после того, как он его окончательно введет, а динамически перерассчитать разметку после того, как пользователь закончит изменять размер окна.

var lazyLayout = _.debounce(calculateLayout, 300);
$(window).resize(lazyLayout);

Прошу прощения, но я не совсем понимаю как оно способствует улучшению производительности?
По-умолчанию по-моему работает логично:
If no tracking function is specified the ng-repeat associates elements by identity in the collection. It is an error to have more than one tracking function to resolve to the same key.
Переводить на стал т.к. лучше отписать оригиналом, чем ломать его своим переводом.

я сломаю:
Если нет функция отслеживания, это указывает, что "ng-repeat" связывает элементы по идентичности в коллекции. Ошибка, если имеется более чем одна отслеживающая функция возвращающая тот же самый ключ.

Что такое "идентичность"? В рамках ангуляра отслеживание изменений по значению. А что такое отслеживание изменений по значению для массива, в котором лежат объекты? :)

та самая ошибка http://learn.javascript.ru/play/1LGDbc

тем не менее, этот пример http://learn.javascript.ru/play/Qmjpf показывает, что ангуляр пихает ключи в объекты для отслеживания (что не всегда уместно)

Проще всего исходники посмотреть или подебажить, но лениво :)

Спасибо, стало понятней. Фактически мы просто избавляемся от лишних вычислений, особенно если у нас массив объектов.

Черт знает. Если посмотреть исходники

if (trackByExp) {
  trackByExpGetter = $parse(trackByExp);
  trackByIdExpFn = function(key, value, index) {
  // assign key, value, and $index to the locals so that they can be used in hash functions
    if (keyIdentifier) hashFnLocals[keyIdentifier] = key;
      hashFnLocals[valueIdentifier] = value;
      hashFnLocals.$index = index;
      return trackByExpGetter($scope, hashFnLocals);
    };
} else {
  trackByIdArrayFn = function(key, value) {
    return hashKey(value);
  };
  trackByIdObjFn = function(key) {
    return key;
  };
}

то в одном случае будет всегда срабатывать

trackByExpGetter($scope, hashFnLocals);

в другом —

hashKey(value);

Не уверен, что первая быстрее...

Shitbox2, ты хотя бы написал, что ведешь речь о ng-repeat =)

ну смотри, в случае

ng-repeat="item in array"

у тебя получается, что: если item is object, то к каждому item будет впиндюрен (непереводимое слово :) $$hashKey + создана функция слежения (привет Бараку Обаме)
а в кейсе вида

ng-repeat="item in array track by item.id"

будет создана только функция слежения

---

А еще я забавный паттерн "изобрел" :D для сборки мусора:
1. в директиве

function(scope, element, attrubutes) {
    element.bind('$destroy', scope.$watch(watcher, handler));
}

2. в контроллере

function($scope) {
    $scope.$on('$destroy', $scope.$watch(watcher, handler));
}

и все счастливы =)

nerv_, что думаешь насчёт https://github.com/Pasvaz/bindonce ?

я глянул демку, но особо не вникал

я тоже глянул. И что-то разницы не увидел =)

то бишь ввод текста в поле и там и там тормозит, или нигде не тормозит?)

... а как бы убрать лаг при добавлении 2000 записей? пагинация\бесконечный скролл?

как можно разбить добавление элементов внутри ng-repeat по итерациям setTimeout ?


не шарю :(

тормозит везде

не делать 2000 записей. Пагинация. Можешь взять мой модуль.
либо оптимизации

1. Использовать {{::value}} синтаксис, когда нет необходимости обновлять данные (доступно в 1.3.0 beta)
Пример

2. Делать больше DOM манипуляций в директиве
Вместо

<div ng-show=”something”></div>

$scope.something = false;
$scope.someMethod = function () {
  $scope.something = true;
};

Использовать

var menu = $element.find(‘ul’);
menu.hide();
$scope.someMethod = function () {
  menu.show();
};

3. По минимуму использовать фильтры в DOM
Вместо

{{ array | filter : expression : comparator }}

Использовать

scope.result = $filter('filter')(array, expression, comparator);

4. В часто вызываемых функциях mousemove, mouseover, mouseout и т.п. не использовать лишний раз $apply или $digest

FireVolkhov, не проще тогда просто выкинуть angular на мороз и сразу писать по-человечески?)
В чём прикол фич которые всё равно нельзя использовать?)

"и сразу писать по-человечески?)" это как?:blink:
Прикол фитч в том, чтобы использовать их вмеру

не факт, что в stable будет эта возможность

Или неудачный пример... или... в чем смысл? Все равно watcher вешать и делать тоже самое, что и директивы ng-show|ng-hide. Т.е. выигрыша нет.

уже писали)

---

научи =)

Node.appendChild

Node.insertAdjacentHTML

... всему вас нужно учить :)


PS вообще, ни разу ещё не страдал от фильтров в DOM (профилирование, йопт)

больше всего ненавижу ng-view (или ui-view) или ng-repeat. и ещё $watch - обычно вырубаю его , где могу (т.е. где оно не нужно... а оно не нужно много где)

Да пример может не совсем удачный вот другой, суть выходит сводится к "использовать минимум watcher'ов", стараться не использовать watcher для коммуникаций внутри директивы, только для работы с другими директивами, контроллерами, сервисами.

При таком примере "теряется" MVC - так я не могу управлять видимостью из модели. На мой взгляд ценность такой директивы невелика)

Кроме того

content.toggleClass('ng-hide', !show);

я вот тут статью в тему перевел - "Оптимизируем AngularJS. Подробный разбор."
от Глеба Бахмутова

nerv_,
Стало частью stable можно дописывать

UPD:
Не делать многократного вложение директив в директивы, если нужна повторяющаяся логика использовать вложенные контроллеры

angular.module '...'
	.directive 'dateTextfield', ($controller, ...) ->
		link: (scope, elem, attrs) ->
			commonHintCtrl = $controller 'CommonHintCtrl',
				$scope: scope
				...

Angular performance optimization works well when we use lazy modules, lazy modules helps to break the large chunks of codes into small so Angular JS would be optimized.