Nano Hash - криптовалюты, майнинг, программирование

Как оптимизировать скорость рендеринга усов при рендеринге более 8000 элементов?

Я пытаюсь отобразить таблицу, поэтому шаблон довольно прост; шаблон строки выглядит так:

  <script type=\"text/mustache\" id=\"template-list-records\">
  {{#.}}
   <tr>
    <td>{{airport_code}}</td>
    <td>{{city_code}}</td>
    <td class=\"pull-right\">
     [<a href=\"result.mics?m_uid={{airport_code}}\" class=\"listlink\">details</a>]
    </td>
   </tr>
  {{/.}}
  </script>

Проблема в том, что скорость рендеринга начинает экспоненциально замедляться при рендеринге более 1000 результатов (я предполагаю, что она замедляется экспоненциально все время :), но с 1000+ результатов заметно, что скорость рендеринга нелинейна). Теперь при 4000 результатов страница загружается за 2,3 секунды. При 7000 результатов время рендеринга составляет 7,3 секунды, а рендеринг всего набора результатов (около 8500 результатов) занимает 10 секунд. Теперь мне не нужно ускорять его быстрее, чем 8 секунд для полной загрузки результата (так как это количество времени, которое старый функционал требовал для отображения страницы), это было бы бонусом :), но мне все еще нужно побрить 2 секунды. Я посмотрел в инспекторе Timeline, время уходит на рендеринг; рендеринг начинается через 2,5 секунды.

Я предполагаю, что часть проблемы может быть связана с моим ноутбуком (у меня есть некоторые проблемы с графической картой), но все же мне интересно, есть ли способ ускорить это, например. предварительно скомпилируйте таблицу с 8500 строками и при необходимости добавьте/удалите строки (это действительно таблица со списком аэропортов, поэтому число меняется не часто, а когда и меняется, то не сильно).


Ответы:


1

Новая идея: почему бы тогда не отображать страницу постепенно? Я предполагаю, что 8500 строк — это довольно много «страниц» (конечно, около 200 «страниц» на экране 1080p), поэтому вы можете легко реализовать механизм непрерывной прокрутки, при котором вы продолжаете отображать данные небольшими фрагментами по мере необходимости.

Скажем, для начала вы начинаете рендерить первые 500 элементов (что уже много), затем, когда пользователь начинает прокручивать и приближается к 80% от общего размера прокрутки, вы рендерите 200 дополнительных строк. Вы продолжаете делать это, пока не закончатся строки для рендеринга.

В случае, если у вас есть требование, в котором говорится, что вам нужно иметь все доступное сразу (чтобы пользователи могли, например, нажать Ctrl + F), вы все равно можете попробовать рендеринг по частям: вместо того, чтобы вводить в свой шаблон весь набор данных, разбейте его. в наборах по 500 и вызывайте Усы столько раз, сколько необходимо с этими меньшими наборами. Если он по-прежнему забивается, добавьте небольшой тайм-аут между вызовами, чтобы улучшить воспринимаемую отзывчивость.

TBH, я перечитал ваш вопрос, и, похоже, большую часть вашего времени вы тратите на то, чтобы браузер вычислил макет вашей таблицы, поэтому эти предложения должны подойти для вашего случая. В крайнем случае вы можете попробовать использовать CSS table-layout: fixed;, который значительно ускорит рендеринг вашей таблицы, но также, в свою очередь, заставит вас вручную определять ширину столбцов, поскольку таблица больше не будет динамически адаптировать ширину столбцов в зависимости от ее содержимого.

16.01.2013
  • У меня есть требование CTRL+F, иначе я бы реализовал нашу классическую подкачку 50+ элементов. Я попытаюсь разбить рендеринг на куски и посмотреть, что получится. 17.01.2013
  • Я пытался реализовать это и в процессе понял, что проблема не столько в Усе/Хогане, проблема, похоже, в Backbone.js. Я выполняю рендеринг в Backbone.View, я расширил метод рендеринга, и этот метод требует времени для выхода/рендеринга, поэтому мне придется взглянуть на оптимизацию Backbone.js. 17.01.2013
  • В конце концов, я решил просто получить 10 результатов и выполнить пейджинг. Но я также обнаружил проблему - моя реализация парсера. Правильная реализация — парсинг всех результатов и объединение их в памяти, и только после этого вывод результата. Моя реализация отображала и добавляла каждый элемент (обновляла DOM), что вызывало перерисовку... около 8000 раз :D Сейчас это смешно, но не тогда, когда я спрашивал :) 01.05.2016

  • 2

    Пробовали ли вы альтернативные реализации Mustache, такие как Hogan или Рули?

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

    Кроме того, если вы еще не используете последнюю версию Mustache.js, вы можете просто обновить ее. Старые версии (около 1,5 лет) имели серьезные проблемы с производительностью.

    16.01.2013
  • Версия усов не имеет значения, я пробовал рендеринг с последней версией, скорость та же. Я читал о Hogan/Handlebars, но надеялся, что что-то можно сделать только с Mustache. 16.01.2013
  • Хоган это просто Усы, и синтаксис, и его интерпретация остаются верными Усам. spec, поэтому, в отличие от Handlebars, у вас не будет соблазна отчуждать ваши шаблоны. Вы даже можете написать оболочку поверх Hogan, чтобы избежать обновления всего вашего кода для использования нового API, по крайней мере, в целях тестирования. 16.01.2013
  • Я собираюсь попробовать Hogan и открыть новый вопрос о проблемах с Hogan.js :) 16.01.2013
  • Мне удалось разобрать с Хоганом, но я все еще получаю ту же скорость :( 16.01.2013
  • Добавим еще один ответ теперь, когда мы определили, что проблема заключается в количестве данных, а не в алгоритме. 16.01.2013

  • 3

    Как добавить HTML-код с усами в DOM?

    Попробуйте добавить визуализированный код в одну точку вместо непрерывной вставки.

    медленно, много вставок:

    for () {
      table.innerHTML = table.innerHTML + Mustache.render(row);
    }
    

    быстрее, 1 вставка:

    var buffer = '';
    for () {
      buffer = buffer + Mustache.render(row);
    }
    table.innerHTML = buffer;
    
    28.08.2014
  • Проблема была решена с помощью пропечатанной функциональности, но я думаю, что настоящая проблема была, как вы упомянули, вставкой/рендерингом DOM. 30.09.2014
  • Новые материалы

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

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

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

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

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

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..