Если не надо реагировать на изменения, то нахера mobx? Не пойму что вы тут всё пытаетесь придумать, данные меняются, нужно перестраивать все вычисляемые данные.
Даже не знаю как вам объяснить :) myBigDataSet и является источником нужных для рендера данных, из него данные могут сортироваться, фильтроваться и использоваться в различных представлениях.
В том как всё это делать эффективно. Например при переходах страниц нужно эффективно выстраивать большой граф, тк в это же время от нашего бюджета по времени исполнения очень сильно отожрут такие задачи как генерация большого куска DOM страницы, рекалк стайл, лэйаут, пэйнт, композиция.
Я специально продемонстрировал пример с фильтрацией. Сортировка и фильтрация — это типичная задача с datatable'ами когда используется occlusion culling и на экране отображается пара десяткой рядов, а в памяти лежит несколько тысяч.
Вы сравнили react и vdom, mobx к этому не причастен
vdom дифф в списке просто для того чтоб примерно представлять относительный оверхэд (чтоб понять с какой скоростью на моей машине исполняется такая задача, иначе абсолютные цифры вообще ни о чём не будут говорить)
Тем более 5000 элементов из списка никто в здравом уме не будет пихать в DOM
О чудо, в этом и суть реакта! Посмотрите выступления когда о реакте ещё никто не знал, одна из задач которую решали при разработке реакта — это то что на экране отображается значительно меньше того что находится в памяти, поэтому и отказались от построения fine-grained графа зависимостей.
Это только лишь при исполнении экшена, расход памяти на построение новых связей в computed'е. Расход памяти и производительность построения ObservableValue я не учитывал, каждый ObservableValue это слоты на 8 свойств + 1 Set() + динамически генерируемая строка. Если вас это устраивает, то пользуйтесь, меня это не устраивает.
а где цифры в милисекундах говорящие о тормозной работе? Это заняло столько-то, это столько-то и т.д.
В милисекундах относительно чего? Просто так говорить о милисекундах не сравнивая это с чем-то не имеет никакого смысла, можете измерить у себя на машине и сделать выводы.
Разница при исполнении между observable и обычными свойствами у Item — ~650kb. Эффективная vdom либа во время диффа 2500 ДОМ элементов даже не жрёт столько памяти.
Но тут не только проблема в памяти, а в том как реализован алгоритм подписки/отписки зависимостей в mobx, как-то он очень тормозно отрабатывает даже после того как jit разогреется.
Пробежался сейчас по исходникам mobx, они всё же отлавливают повторные обращения во время исполнения, так что да, связи будут расти линейно. Но как же там всё неэффективно реализовано.
Накидал простой пример:
class Item {
a = 0;
b = 0;
}
decorate(Item, { a: observable, b: observable });
class Items {
filter = 0;
all = [];
get filtered() {
return this.all.filter((i) => i[this.filter ? "a" : "b"] === -1);
}
click() {
this.filter ^= 1;
}
}
decorate(Items, {
filterValue: observable,
all: observable,
filtered: computed,
click: action,
});
const Store = new Items();
transaction(() => {
for (let i = 0; i < 5000; i++) {
Store.all.push(new Item());
}
})
Смотрю что происходит в профайлере во время исполнения экшена и как он жрёт память и что-то мне не нравится такая производительность и такой оверхэд по памяти. Для большинства задач он конечно же справится нормально, но всё же это не silver bullet.
Вопрос для тех кто топит за mobx и подобные решения. На юз кэйсах когда нужно сортировать/ фильтровать большой массив данных до сих пор строится громадный граф зависимостей с кучей повторяющихся связей или всё же придумали какие-то вменяемые алгоритмы (перестал активно следить за темой пару лет взад)?
А причём тут реакт вообще? Речь исключительно про преакт, 8ка вообще на куче кэйсов работает некорректно, а 10ка использует алгоритмы с мутабельным вдомом которые были актуальны в 2016ом. Но суть не в этом, а в том как там пишут код ради того чтоб сократить пару десятков байт.
Я думаю что имелось в виду то что для конечного пользователя гораздо важнее время которое будет потрачено на исполнение задачи в целом, а не только парсинга. К примеру можно пытаться экономить каждый байтик ради маркетинговых целей как в преакте и получить в итоге тормозное решение. Нужно пытаться оптимизировать размер кода, но не стоит делать это в ущерб производительности.
На самом деле это очевидные мелочи, если не замарачиваться на тему производительности и в первую очередь думать о композиционных паттернах. Например, в моей старой библиотеке невозможно было менять рутовый элемент у компонент и это было ограничено на уровне API, а так как остальные библиотеки использовали те же самые алгоритмы, но при этом пытались делать API как у React'а, то естественно во всех библиотеках кроме реакта это не работало, и когда я рассказал другим об этой проблеме и сказал что нормальный фикс потребует изменить код в куче мест, большинство разработчиков пошли простым путём и начали использовать корявый фикс, который в случае таких кэйсов рекурсивно шёл по дереву вверх и патчил все несоответствия, в некоторых либах это даже приводило к тому что изменялся шэйп виртуальных нодов и повсюду срабатывали деоптимизации с мономорфных колсайтов на полиморфные, но так как в популярных бэнчмарках этот кэйс не проявляется, то никто не замарачивался :) В некоторых библиотеках этот кэйс до сих пор поломан.
Потом всплыла проблема с условным рендерингом, во всех вдом библиотеках кроме реакта, условный рендеринг в некоторых ситуациях приводил к тому что соседние элементы/компоненты теряли внутреннее состояние и чтоб нормально пофиксить эту проблему нужно либо полностью переписывать дифф алгоритм, либо сделать корявый фикс (как в реакте) и получить проседание в производительности на большинстве кэйсов со статическими листами, но так как почему-то разработчики популярных библиотек не в состоянии переписать алгоритмы, учитывая этот кэйс, то для того чтоб демонстрировать хорошую производительность на микробэнчмарках некоторые разработчики библиотек начали исползовать специальные флаги для "продвинутых" оптимизаций. Большая часть вдом библиотек до сих пор не учитывает этот кэйс.
Все эти проблемы я отношу к фундаментальным проблемам, но так как у реакта очень большая популярность, то им дополнительно приходится фиксить кучу проблем связаных с нормализацией поведения в различных браузерах. Например во vue долгое время закрывали issues'ы связаные с поведением innerHTML на svg элементах, и только когда накопилась критическая масса недовольных пользователей, то наконец-то это пофиксили. Недавно во vue начали появляться недовольные пользователи, у которых инпут поля работают неправильно в некоторых браузерах из-за порядка присваивания аттрибутов, но так как кол-во недовольных пользователей пока маленькое, то естественно там забивают на эту проблему, а в реакте из-за его популярности пришлось нормализовать поведение для всех этих мелких кэйсов и многих других, тк недовольных пользователей значительно больше.
Надо ещё учитывать расход памяти, константные затраты на операцию, кэш миссы итд. Ну или можно просто смотреть на цифры в профайлере/бэнчмарках.
В том как всё это делать эффективно.
https://habr.com/ru/post/459706/#comment_20387548
Свойства
aиb— observable.Если не надо реагировать на изменения, то нахера mobx? Не пойму что вы тут всё пытаетесь придумать, данные меняются, нужно перестраивать все вычисляемые данные.
Даже не знаю как вам объяснить :)
myBigDataSetи является источником нужных для рендера данных, из него данные могут сортироваться, фильтроваться и использоваться в различных представлениях.А теперь перечитайте что вы там предлагаете в предыдущем своём комментарии :)
И нахера тогда mobx? Что-то у меня сомнения в том что вы что-либо делали с использованием mobx :)
В том как всё это делать эффективно. Например при переходах страниц нужно эффективно выстраивать большой граф, тк в это же время от нашего бюджета по времени исполнения очень сильно отожрут такие задачи как генерация большого куска DOM страницы, рекалк стайл, лэйаут, пэйнт, композиция.
Я специально продемонстрировал пример с фильтрацией. Сортировка и фильтрация — это типичная задача с datatable'ами когда используется occlusion culling и на экране отображается пара десяткой рядов, а в памяти лежит несколько тысяч.
vdom дифф в списке просто для того чтоб примерно представлять относительный оверхэд (чтоб понять с какой скоростью на моей машине исполняется такая задача, иначе абсолютные цифры вообще ни о чём не будут говорить)
О чудо, в этом и суть реакта! Посмотрите выступления когда о реакте ещё никто не знал, одна из задач которую решали при разработке реакта — это то что на экране отображается значительно меньше того что находится в памяти, поэтому и отказались от построения fine-grained графа зависимостей.
Цифры на моей машине:
onClickобработчик (Itemс observable свойствами): 6мсonClickобработчик (Itemс обычными свойствами): 1.5мсЭто только лишь при исполнении экшена, расход памяти на построение новых связей в computed'е. Расход памяти и производительность построения
ObservableValueя не учитывал, каждыйObservableValueэто слоты на 8 свойств + 1Set()+ динамически генерируемая строка. Если вас это устраивает, то пользуйтесь, меня это не устраивает.В милисекундах относительно чего? Просто так говорить о милисекундах не сравнивая это с чем-то не имеет никакого смысла, можете измерить у себя на машине и сделать выводы.
Разница при исполнении между observable и обычными свойствами у
Item— ~650kb. Эффективная vdom либа во время диффа 2500 ДОМ элементов даже не жрёт столько памяти.Но тут не только проблема в памяти, а в том как реализован алгоритм подписки/отписки зависимостей в mobx, как-то он очень тормозно отрабатывает даже после того как jit разогреется.
Пробежался сейчас по исходникам mobx, они всё же отлавливают повторные обращения во время исполнения, так что да, связи будут расти линейно. Но как же там всё неэффективно реализовано.
Накидал простой пример:
Смотрю что происходит в профайлере во время исполнения экшена и как он жрёт память и что-то мне не нравится такая производительность и такой оверхэд по памяти. Для большинства задач он конечно же справится нормально, но всё же это не silver bullet.
Даже в случае сортировки, когда к одним и тем же обсёрвабл свойствам обращаются по нескольку раз?
Всё просто замечательно :D
Вопрос для тех кто топит за mobx и подобные решения. На юз кэйсах когда нужно сортировать/ фильтровать большой массив данных до сих пор строится громадный граф зависимостей с кучей повторяющихся связей или всё же придумали какие-то вменяемые алгоритмы (перестал активно следить за темой пару лет взад)?
А причём тут реакт вообще? Речь исключительно про преакт, 8ка вообще на куче кэйсов работает некорректно, а 10ка использует алгоритмы с мутабельным вдомом которые были актуальны в 2016ом. Но суть не в этом, а в том как там пишут код ради того чтоб сократить пару десятков байт.
Я думаю что имелось в виду то что для конечного пользователя гораздо важнее время которое будет потрачено на исполнение задачи в целом, а не только парсинга. К примеру можно пытаться экономить каждый байтик ради маркетинговых целей как в преакте и получить в итоге тормозное решение. Нужно пытаться оптимизировать размер кода, но не стоит делать это в ущерб производительности.
«The rendering layer has been rewritten using a light-weight Virtual DOM implementation forked from snabbdom»
На самом деле это очевидные мелочи, если не замарачиваться на тему производительности и в первую очередь думать о композиционных паттернах. Например, в моей старой библиотеке невозможно было менять рутовый элемент у компонент и это было ограничено на уровне API, а так как остальные библиотеки использовали те же самые алгоритмы, но при этом пытались делать API как у React'а, то естественно во всех библиотеках кроме реакта это не работало, и когда я рассказал другим об этой проблеме и сказал что нормальный фикс потребует изменить код в куче мест, большинство разработчиков пошли простым путём и начали использовать корявый фикс, который в случае таких кэйсов рекурсивно шёл по дереву вверх и патчил все несоответствия, в некоторых либах это даже приводило к тому что изменялся шэйп виртуальных нодов и повсюду срабатывали деоптимизации с мономорфных колсайтов на полиморфные, но так как в популярных бэнчмарках этот кэйс не проявляется, то никто не замарачивался :) В некоторых библиотеках этот кэйс до сих пор поломан.
Потом всплыла проблема с условным рендерингом, во всех вдом библиотеках кроме реакта, условный рендеринг в некоторых ситуациях приводил к тому что соседние элементы/компоненты теряли внутреннее состояние и чтоб нормально пофиксить эту проблему нужно либо полностью переписывать дифф алгоритм, либо сделать корявый фикс (как в реакте) и получить проседание в производительности на большинстве кэйсов со статическими листами, но так как почему-то разработчики популярных библиотек не в состоянии переписать алгоритмы, учитывая этот кэйс, то для того чтоб демонстрировать хорошую производительность на микробэнчмарках некоторые разработчики библиотек начали исползовать специальные флаги для "продвинутых" оптимизаций. Большая часть вдом библиотек до сих пор не учитывает этот кэйс.
Дальше там всякие проблемы из-за использования мутабельных нодов, проблемы с алгоритмами нормализации чилдрен листов, которые ограничивают возможности композиции.
Все эти проблемы я отношу к фундаментальным проблемам, но так как у реакта очень большая популярность, то им дополнительно приходится фиксить кучу проблем связаных с нормализацией поведения в различных браузерах. Например во vue долгое время закрывали issues'ы связаные с поведением innerHTML на svg элементах, и только когда накопилась критическая масса недовольных пользователей, то наконец-то это пофиксили. Недавно во vue начали появляться недовольные пользователи, у которых инпут поля работают неправильно в некоторых браузерах из-за порядка присваивания аттрибутов, но так как кол-во недовольных пользователей пока маленькое, то естественно там забивают на эту проблему, а в реакте из-за его популярности пришлось нормализовать поведение для всех этих мелких кэйсов и многих других, тк недовольных пользователей значительно больше.