Comments 17
Я сейчас только в процессе изучения AngularJS, поэтому возникает вопрос — реально ли упереться в производительность на реальных проектах (а не синтетических тестах) при стандартном использовании scope?
Зависит от задачи. Все что часто и много меняет DOM будет педалить, производительность падает линейно по мере роста количества ватчеров, повсеместное использование директив типа ng-click и т.д. вместо делигирования событий так же доставляет неудобства. Но решать проблемы до их появления не стоит, можно сделать только хуже.
Вполне реально, вывод списка >500 элементов (6 watcher'ов на элемент) уже заметно (~1s) тормозит, конечно, это если не пользоваться bind-once и иже с ним. Причем тормозит именно отрисовка, фильтрация или еще какие _внутренние_ действия над списком проходят без тормозов.
Вот к чему я и спрашивал. По-моему скромному опыту не могу вспомнить ситуацию, где необходимо было отрисовывать 500 итемов разом. Но возможно у меня все еще впереди. )
Вывод списка зарегистрированных людей на мероприятие, было грубейшей ошибкой с моей стороны выводить все это одним сплошным списком, по крайней мере в том виде, в котором я это сделал, сейчас я бы для этого использовал разбитую на страницы табличку еще и с bind-once в придачу :) Так что упереться можно, легко, но и избавиться от этого так же легко.
Как только у вас появится задача добавить бесконечный скрол — сталкнетесь. Вот там уйма возможностей по оптимизации.
Вот годные рассуждения на тему произвоительности AngularJS от одного из его авторов. Но в общем случае, все действительно зависит от того на сколько часто будут вызываться обработчики $watch и на сколько большим будет сравниваемый scope.
По идее, если в директиве «mover» изолировать scope, в ней же повесить вручную на элемент событие «mousemove», а внутри обработчика вызывать scope.$digest(), результат должен быть примерно такой же как в быстрой версии. Как то так fiddle
да, результат будет быстрее. Это как раз пример локальных улучшений, о которых я говорил в начале статьи.
В этом примере можно не использовать ангуляр, можно обойтись querySelector и innerHtml, будет наверно еще быстрее.
В большом проекте мест, где можно использовать локальные улучшения очень много и если с каждым возиться и думать, как его улучшить, уйдет очень много времени и будет очень много костылей.
В этом примере можно не использовать ангуляр, можно обойтись querySelector и innerHtml, будет наверно еще быстрее.
В большом проекте мест, где можно использовать локальные улучшения очень много и если с каждым возиться и думать, как его улучшить, уйдет очень много времени и будет очень много костылей.
В большом проекте, рано или позно возникнут проблемы от подобного разделения, чаще всего у блоков на одной странице есть что-то общее и они должны как-то общаться, например сервисами или родительскими контроллерами. Для небольших изолированных блоков вполне подходят директивы, а если два больших блока на столько изолированы, что требуют разделения на корневые модули — их соседство на странице сомнительно. Это, конечно, имхо)
Согласен. Полностью изолированные бывают крайне редко.
В текущем проекте связываю модули через события в модели (неангуляровские) и дергаю $scope.$apply в обработчике. Но данный подход мне не очень нравится, поэтому не включал его в статью.
Спасибо за комментарий, становится понятно чему уделять внимание.
В текущем проекте связываю модули через события в модели (неангуляровские) и дергаю $scope.$apply в обработчике. Но данный подход мне не очень нравится, поэтому не включал его в статью.
Спасибо за комментарий, становится понятно чему уделять внимание.
Простите, но предложенное вами решение — тоже кастыль.
Sign up to leave a comment.
Разделение приложения AngularJS на изолированные модули