Производительность Angularjs при создании элементов dom, pure js vs jqlite

Question

У меня есть директива в Angularjs, которая будет иметь таблицу с большим количеством строк (более 1000), поэтому мой босс сказал, что я не должен использовать привязку, чтобы сделать содержимое сетки (из-за ограничения углов ~ 2000 в привязке), и вместо этого я должен создавать элементы dom на лету.

И я сделал это с angular.element(...), и он работает. НО теперь я думаю, если может быть повышение производительности, если я использую нативный js document.createElement?

Так jqlite медленнее, чем чистый js? как сильно это повлияет при создании более 1000 строк html?

jquery быстрее? Медленнее или равно jqlite?

UPDATE:

@Joe Enzminger +1 за один раз связывания было бы хорошо для отчета/печать вида ведьмы просто для просмотра. НО сетка имеет встроенное редактирование, поэтому ему нужны двусторонние привязки. он имеет 19 столбцов с входом и двумя кнопками и кнопкой сохранения в последнем столбце. каждая кнопка имеет ng-show, а кнопка сохранения имеет ng-class, чтобы изменить значок на основе состояния строк. поэтому (19 * 3) +1 двусторонние привязки.

Эта сетка является формой ввода данных для некоторых кинов: D, и все строки должны быть видимыми и не иметь разбивки на страницы.

UPDATE2:

Я забыл упомянуть, что сейчас у меня есть пустой tbody элемент в шаблоне, и все его содержимое генерируется в виде простой йот и вводят в него абсолютно без привязки данных любого рода. все взаимодействия обрабатываются с хорошим модным JS вручную: D.

Answer 1

Я уверен, что один из них «быстрее». Однако, возможно, только незначительно - я не думаю, что есть много шансов на то, что вы будете использовать его по сравнению с другими.

Однако, с точки зрения ремонтопригодности, я бы предложил использовать функцию привязки Angular. Мифический предел привязки «~ 2000» действительно относится к часам, а не к привязкам, и на самом деле не является лимитом, а не ориентиром. Используя {{:: var}} внутри ng-repeat, вы получите гораздо более удобный код с сопоставимой производительностью, чем создание пользовательского DOM на лету, и он не будет создавать $ watch, которые могут повлиять на производительность.

Answer 2

Здесь есть две вещи: производительность рендеринга DOM и производительность углового $ watch ($ digest). В обоих случаях попытка оптимизации document.createElement против angular.element не стоит.

Для рендеринга DOM узким местом является не скорость выполнения JavaScript, а просмотр браузера (см.: html5rocks) и пересчеты (см.: Google developers). Используете ли вы document.createElement или angular.element, это незначительно, потому что поражение производительности и блокировка пользовательского интерфейса приходят, когда вы добавляете или изменяете элементы на странице, а не при создании элементов DOM в памяти. Вот почему большинство современных интерфейсов пользовательского интерфейса пакет DOM обновляет, а не делает много мелких обновлений (например, ReactJS, Meteor, EmberJS).

За $ смотреть и $ переваривать производительности, снижение производительности происходит от количества и сложностей связывания выражений (например, {{things}}, ng-bind, ng-show, ng-class, и т.д.), что угловой должно оценить в каждых $ переваривать цикл.Если вы помните, что в большинстве случаев простое действие, подобное щелчку, вызывает цикл $ digest, тысячи привязок могут быть оценены при каждом нажатии. Рекомендуется использовать одноразовые привязки для минимизации количества часов и следить за тем, чтобы часы были максимально простыми.

В директиве по умолчанию ng-repeat (предположительно, что вы используете для создания сетки) у вас действительно нет прекрасного контроля над этими двумя соображениями, кроме как максимально возможного использования одноразовых двусторонних привязок или обрезки ваших модель данных. Именно поэтому разработчики, чувствительные к производительности, обходят ng-repeat полностью и create their own directives. Если производительность является ключевой для вас, вы должны изучить что-то подобное.