#jquery #performance #jqplot
#jquery #Производительность #jqplot
Вопрос:
У меня есть приложение, которое использует jqPlot, и я хочу, чтобы оно работало лучше, то есть быстрее отображало диаграммы.
Используя профилировщик Firefox, я могу детализировать время, затрачиваемое на различные части кода, и я обнаружил, что вызов jqplot занимает ~ 85% времени. Из этих 85% ~ 60% тратится на jqplot.процедура рисования и ~ 20% берется в процедуре jqplot.parseOptions.
В дополнение к статическим данным конфигурации (информация, связанная с легендой, информация, связанная с таблицей, информация о курсоре и маркере, а также информация об осях x, y, y1 и y2), фактические данные диаграммы передаются в объекте option в jqplot. Данные диаграммы включают данные ряда, параметры ряда и метки меток.
jqplot копирует все эти данные в свою собственную память и делает это с помощью функции parseOptions, которая использует функцию jquery.extend() для выполнения работы. Функция jquery.extend представляется функцией копирования общего назначения, которая знает, как работать со всеми типами данных и объектами, но, как и любая обобщенная функция, она не оптимизирована ни для одного из них.
Моей первой попыткой было просто передать статические параметры при вызове jqplot, а затем использовать jqplot.replot() для передачи данных серии, параметров серии и тиков в объект диаграммы (чтобы избежать расширения в parseOptions). Это не удалось, и после того, как я проследил код, я обнаружил, что replot принимает только данные линейного графика (точки x, y) и не принимает данные OHLC (из которых состоит большинство этих диаграмм). Затем я попытался передать данные OHLC при первоначальном вызове jqplot и передать параметры серии и тики при последующем вызове replot, но, хотя в (ограниченной) документации jqplot говорится, что replot будет принимать опции, это не полный набор опций, и те, которые мне были нужны, не были обработаны.
Моей следующей попыткой было сделать series_options «легче». Данные первичного ряда для диаграммы используют OHLCRenderer, а в других рядах используется LineRenderer. В текущем коде LineRenderer установлен по умолчанию, и каждый объект series_option имеет переопределение, определяющее OHLCRenderer. Каждая из этих ссылок на переопределение OHLCRenderer в объектах series_option имеет под собой несколько объектов — прототипы функций и другие вещи. Поскольку существует всего несколько типов, отличных от sample / wafer, по сравнению с объектами sample / wafer, я изменил ситуацию, чтобы сделать OHLCRenderer по умолчанию и добавил переопределения LineRenderer для этих других объектов. Я думал, что удаление такого количества ссылок на объекты ускорит процесс parseOption, но это не имело заметной разницы (во всяком случае, это казалось немного медленнее, но, поскольку профилирование такое, конечно, непонятно).
На данный момент у меня нет идей. У кого-нибудь есть идеи относительно того, что я мог бы сделать, чтобы ускорить рендеринг диаграммы?
Комментарии:
1. JSPerf или JSFiddle текущего состояния вашего исследования было бы полезно для людей, чтобы полностью понять повествование и обеспечить основу для демонстрации того, что любой предложенный подход действительно лучше.
2. Каким бы полезным это ни было, для this или jsFiddle мне нужно было бы иметь большой объем сохраненных данных в качестве части примера. Данные должны быть очищены, чтобы в них не было никаких проприетарных данных, а затем обработаны строкой, выгружены на консоль и скопированы / вставлены. Это выполнимо, но это потребует больших усилий. Что я надеялся увидеть, так это то, что кто-нибудь уже сталкивался с этой проблемой раньше.