Не бойся, это всего лишь данные... просто их много
2 likes•3,622 views
Документ обсуждает использование данных на клиентской стороне и эффективность обработки больших объемов информации. Автор делится опытом разработки и предлагает методы оптимизации, включая избегание использования DOM для хранения данных. Основной вывод заключается в том, что можно работать с большими объемами моделей на клиентской стороне, если подход реализован аккуратно и эффективно.
![30
Item.prototype.values = function(tr, columns) {
var values = {};
for (var i = 0; i < columns.length; i++) {
var name = columns[i];
var td = tr.getElementsByClassName(name)[0];
values[name] = td ? td.innerHTML : '';
}
return values;
};
Получение значений для поиска](https://image.slidesharecdn.com/big-data-140314034057-phpapp01/85/-30-320.jpg)
Не бойся, это всего лишь данные... просто их много
- 1. Не бойся,это всего лишь данные... просто их много Роман Дворнов Ostrovok.ru
- 2. О себе •Работаю в Ostrovok.ru •Автор фреймворка basis.js 2
- 3. Данные 3
- 4. Когда говорят про данные на client-side, чаще всего, подразумевают объекты и их наборы (модели и коллекции) 4
- 5. Сегодня есть опыт, разнообразные библиотеки, быстрые браузеры, мощные API... 5
- 6. ... но многие по-прежнему скептически относятся к сложным вычислениям и системам на client-side 6
- 8. Все ли так плохо? 8
- 9. Хороший «плохой» пример 9 Или как заставить браузер страдать
- 11. ~10 000 модулей ~2,5 Мб JSON 11
- 12. ~10 000 модулей ~2,5 Мб JSON ~8 сек браузер "висит"! 12
- 13. ААааа!!!!.. Все пропало!... Нужно грузить постранично...
- 14. 14 Постойте, не так быстро...
- 15. Почему? 15
- 16. Что делает скрипт 16 • загружает JSON (массив объектов) • генерирует 4 небольших списка • генерирует таблицу на ~10 000 строк • отдает таблицу компоненту, который разбивает её на страницы и удаляет все строки, кроме первых десяти
- 17. 17 Timeline – Что делает браузер
- 18. Что делает браузер • javascript ~2,85 сек • парсиг html (из шаблонов) ~0,75 сек • расчет стилей ~1,6 сек • layout (~200 000 узлов) ~2.8 сек • еще несколько секунд асинхронно (по 100) "индексируются" строки для поиска 18
- 20. Можно! • генерация представлений ~0,04 сек • применение данных ~0,15* сек 20 * и можно быстрее lahmatiy.github.io/bower-search github.com/lahmatiy/bower-search
- 21. 21 Timeline – Применение данных только JavaScript – ничего лишнего
- 22. Чак одобряет 22
- 23. Хорошие новости: Переделали – теперь работает быстро 23
- 24. Вывод: Дело не в количестве данных, а в неэффективном подходе 24
- 26. Многие веб-разработчики думают через призму jQuery-like подходов, размышляют про данные через представление (верстку) 26
- 27. 27 Пара примеров По мотивам «старого» bower.io/search
- 28. 28 + = $('#components') .find('.created time, .updated time') .timeago(); Разметка ради разметки
- 29. 29 Невидимая ячейка, ее innerHTML используется для поиска
- 30. 30 Item.prototype.values = function(tr, columns) { var values = {}; for (var i = 0; i < columns.length; i++) { var name = columns[i]; var td = tr.getElementsByClassName(name)[0]; values[name] = td ? td.innerHTML : ''; } return values; }; Получение значений для поиска
- 33. В общем случае 31 HTML DOMData
- 34. В общем случае 31 Data* HTML DOMData
- 35. В общем случае 31 Data* HTML DOMData
- 36. В общем случае 31 Data* HTML DOMData
- 37. В общем случае 31 Data* HTML DOMData WTF?!
- 38. В общем случае 31 Data* HTML DOMData WTF?! Данные в исходном виде
- 39. Фактически, DOM используется как хранилище данных 32
- 40. И это самое медленное, что можно придумать 33
- 41. 8,0 с vs. 0,2 с 34 40 : 1 Цифры говорят сами за себя
- 42. Не используйте DOM для хранения данных! 35
- 44. Работа с данными – вне представлений, в абстрактном слое 37
- 45. Задача представлений – отражать состояние данных 38
- 50. Helpers Helpers Идеальный вариант + хелперы 40 Data DOM View bindings ... Model Collection ...
- 51. Хелперы упрощают разработку, но добавляют overhead 41
- 52. Быстрая работа с DOM 42 Наиболее перспективное направление DOM-based templates Фреймворки: React, Ractive, Meteor, Basis.js... Доклад «Как построить DOM» tinyurl.com/build-dom
- 53. Быстрая работа с данными 43 Практически никто об этом не думает :( Якобы основная проблема – рендеринг
- 54. Модель ≠ представление 44 Данных может быть гораздо больше, чем представлений
- 56. bower.io/search 45 10 000+ модулей кастомные выборки, мгновенная фильтрация и сортировка
- 57. bower.io/search 45 10 000+ модулей без участия сервера кастомные выборки, мгновенная фильтрация и сортировка
- 58. Демо блог – 5 000 постов 46 показываем постранично Имея все посты генерируем облако тегов и архив на клиенте tinyurl.com/basis-blog
- 60. С каким количеством моделей мы можем работать? 48
- 61. 1 000 10 000 100 000 1 000 000 ??? 49
- 62. Конечные ресурсы: память и время 50
- 63. Память 51
- 64. Все чего-то стоит • массив: 16bytes • +12bytes + 4bytes/item (для литералов) • +72bytes + 4-8bytes/item (если растить) • объект: 12bytes + 4bytes/property • замыкание: 36bytes • контекст: 24bytes + 4bytes/var 52 * стоимость вV8 (Google Chrome)
- 66. Создание моделей 54 Решение 0 полей 10 полей new basis.data.Object() 240 240 basis.entity.Type() 440 840 new Backbone.Model() 920 1 480 Ember.Object.create() 1 040 1 600 10 000 экземпляров, Кб
- 67. Разные задачи, разные решения 55 • Произвольные поля • Строгий набор полей • Вычисляемые поля • Индекс • Нормализация значений • Defaults • Rollback • ... basis.entity.Entitybasis.data.Object дешево и сердито дороже, но с плюшками
- 68. Event listeners 56 Фреймворк 1 событие 2 события 3 события Basis 240 240 240 Backbone 1 520 2 860 3 840 Ember 5 480 6 520 7 560 10 000 экземпляров, Кб
- 69. Итого 57 Решение 10 полей, 1 listener overhead basis.data 480 5 % basis.entity 1 080 12 % Backbone 3 000 33 % Ember 7 080 79 % 10 000 экземпляров, Кб
- 70. А если пойти дальше... 58
- 71. Интерполяция 59 Решение 1 000 10 000 100 000 basis.data 0, 05 0,5 5 basis.entity 0,1 1 10 Backbone 0,3 3 30 Ember 0,7 7 70 10 полей и 1 listener, Мб
- 72. Вывод №1 О памяти, можно не заботиться когда меньше 10 000 моделей 60
- 73. Вывод №2 Но при больших количествах объектов, расход памяти является серьезной проблемой 61
- 74. Меньше overhead – больше полезной нагрузки 62
- 75. Время 63
- 77. Создание моделей 65 Фреймворк 0 полей 3 поля 10 полей 20 полей basis.data 2 2 2 2 basis.entity 22 6 36 14 105 22 183 35 Backbone.Model 66 123 238 489 Ember.Object 73 128 201 355 10 000 экземпляров, мс
- 78. Event listeners 66 Решение 1 событие 2 события 3 события Basis ~ 0 ~ 0 ~ 0 Backbone 20 29 38 Ember 49 68 89 10 000 экземпляров, мс
- 79. Итого 67 Решение 10 полей, 1 listener overhead basis.data 2 9 % basis.entity 22 100 % Backbone 248 1127 % Ember 250 1136 % 10 000 экземпляров, мс
- 80. А если пойти дальше... 68
- 81. Интерполяция 69 Решение 1 000 10 000 100 000 basis.data ~ 0 2 20 basis.entity 2 22 220 Backbone 25 248 2 480 Ember 25 250 2 500 10 полей и 1 listener, мс
- 82. Это базовое время – быстрее не поедет 70
- 83. Вывод №3 Задачи можно решать по-разному, но не все решения хорошо масштабируются 71
- 84. 72 Вывод №4 Возможно создавать быстрые и дешевые интерфейсы к данным
- 85. Зачем нужны такие оценки? 73
- 86. Чтобы понимать с каким количеством мы можем работать, не причиняя браузеру страдания 74
- 87. Есть задачи, где требуется работать с большим количеством моделей 75
- 89. Rates & AvailabilityView Кастомизированный Excel со сложной логикой, специальными функциями и возможностью редактирования 77
- 90. 78 Клиент для отелей Rates & Availability View
- 91. Масштабы бедствия 79 до 219 000 ячеек Структура отеля до 300 строк (и растет) Даты до 730 колонок (1-2 года) ×
- 92. Как это работает сейчас • По структуре отеля генерируем HTML, вставляем в документ • document.getElementById() ➞ элемент ячейки • Запрашиваем данные – месяц/запрос • Данные – транформируем, создаем модели, настраиваем связи с другими моделями • Добавляем интерактив – обработчики событий и т.д. 80
- 93. Знакомо, не правда ли? 81
- 94. В цифрах • ~5 000 строк vanilla JavaScript, минимум jQuery • ~3,5 с чистое время генерации таблицы (в худшем случае десятки секунд) • ~50 Мб памяти (в худшем случае 100-300 Мб) 82
- 95. Одна из быстрых реализаций с таким подходом 83
- 96. Время и память зависят от размеров и количества данных 84
- 97. Новый функционал Например, не так давно +2 строки/тариф 85
- 98. Средний отель • 25 тарифов × 2 новые строки • = 50 новых строк • = ~18 000 новых ячеек (для года) • = время увеличилось с 3 сек до 3,6 сек (на 16%) 86
- 99. Нужно чтобы было быстрее... 87
- 101. Рисуем только то, что попадает в зону видимости 89
- 103. В видимой области от 200 до 2000 ячеек 91
- 104. Повышенные требования Быстрое создание представлений Быстрая вставка и удаление представлений Переиспользование представлений Быстрое создание моделей Ленивое создание и рассчеты Малое потребление памяти 92
- 105. Повышенные требования Быстрое создание представлений Быстрая вставка и удаление представлений Переиспользование представлений Быстрое создание моделей Ленивое создание и рассчеты Малое потребление памяти 93
- 106. Ленивая обработка данных 94 • JSON.parse • создание моделей • расчеты • GC • JSON.parse • добавление в кеш Отложенное созданиеНемедленное создание В месяце от 1 000 до 10 000 ячеек 40-250мс/месяц 5-25мс/месяц
- 107. Ленивая обработка данных 94 Отложенное созданиеНемедленное создание В месяце от 1 000 до 10 000 ячеек 40-250мс/месяц 5-25мс/месяц x12 ~3,0 сек x24 ~6,0 сек x12 ~0,3 сек x24 ~0,6 сек
- 108. Ленивое создание моделей Создаются только те модели, что попадают во вьюпорт и те, от которых зависит вид отображаемых ячеек 95
- 113. Расчет стиля ячейки 96 rate price price fixed_count flexible_count ... room occupancy occupancy ...
- 116. Старт Время: ~1 секунда без учета сетевых издержек Память: 6-10 Мб с постепенным увеличением при смещении вьюпорта 97
- 117. Scroll 98
- 118. 3 вьюпорта 99
- 119. При сдвиге вычиcляется дельта, какие ячейки нужно удалить и какие добавить 100
- 120. В среднем при сдвиге вьюпорта 101 А могут замениться и все ячейки вьюпорта удаляется 20-250 ячеек добавляется 20-250 ячеек
- 121. Основные операции • Создание моделей • Создание представлений ячеек • Вставка и удаление ячеек • Рассчеты 102
- 122. Основные операции • Создание моделей • Создание представлений ячеек • Вставка и удаление ячеек • Рассчеты 102 Нужно уклыдываться в 16мс
- 124. Scroll Сейчас: 30-40 FPS 103 Цель: 50-60 FPS
- 125. Scroll Сейчас: 30-40 FPS 103 Цель: 50-60 FPS Кажется, вполне достижимо
- 126. Demo 104
- 127. Бонус трек пример простой реализации tinyurl.com/table-scroll 105
- 128. Заключение 106
- 129. Не использовать DOM для хранения данных 107
- 130. Модель ≠ представление 108 данных может быть гораздо больше
- 131. Возможно делать дешевые интерфейсы к данным 109
- 132. Можно работать с сотнями тысяч моделей на client-side 110
- 133. 111 Главное, делать это аккуратно ;)