Pull to refresh

Comments 27

Отлично, итак мне нравилась больше ангуляр. Теперь вообще. Какие типы файлов читает?
Если вопрос касается байндера file, то всех. Байндер сделан на базе FileReader.
Думаю не хватает только одного — таблички аля «can i use» для браузеров. Понятно что таких стариков как ie8 мы уже не помним, но вот с мобильными и всякими не топовыми типа яндекса и вивальди не охото рисковать.
dolphin4ik, Яндекс и Вивальди — это новые браузеры на неустаревших движках. Но идею я понял, добавил в список.
image

Скоро будет на сайте с пояснениями, а список протестированных браузеров будет расширяться (например, Android 4.0 и 4.1). Вивальди и Яндекс сделаны, как и Хромиум, на движке Blink, не виду смысла их добавлять, как и дюжину других локальных форков.
Забыл сказать. Для того, чтоб убедиться самостоятельно, работает ли Матрешка в том или ином браузере, открой в нем эту страницу: coding.farm/matreshka/test/SpecRunner.html

Если всё зеленое, значит, работает. Если красное — дайт мне знать :)
>Теперь в этом же тесте, Матрешка быстрее Реакта на 50 процентов в Хроме, и быстрее в 3 раза в Файерфоксе.

Корявый бэнчмарк с добавлением элемента в конец списка, который является одним из worst case'ов для реакта. Который к тому же запускается на древней версии реакта 0.10.0 в девелопмент режиме (запуск в девелоп режиме в некоторых случаях на порядок медленее), и написан человеком, который явно ничего не писал на реакте.
Могу ли я попросить вас сделать, по-вашему, правильный тест и скинуть мне в личку или ответом на этот комментарий? Внизу каждого бенчмарка есть ссылка «edit these tests or add even more tests to this page».
Начнём с того что нужно забыть о том чтобы бэнчмаркать ui либы на jsperf'е.

Вот один из моих бэнчмарков, который заточен под библиотеки использующие one way dataflow и поддерживают оптимизацию с использованием immutable структур данных: localvoid.github.io/uibench
И глядя на цифры в этом бэнчмарке, я никогда не смогу сказать что одна библиотека быстрее другой в N раз, тк всё очень сильно зависит от тест кэйса.

Если вас реально интересует производительность вашей либы, относительно конкурентов, могли бы сделать какой-нибудь нормальный бэнчмарк, а не эту поделку на jsperf'е, цель которой написать что ваша библиотека быстрее в N раз.

Есть ещё вот такой бэнчмарк: mathieuancelin.github.io/js-repaint-perfs, но опять же нужно понимать что он бэнчмаркает, как работают остальные библиотеки и не делать глупых выводов что одна либа быстрее другой, основываясь на какой-то одной цифре.
Чем вам не угодил JSPerf? Почему мы можем тестировать, скажем, скорость сортировки массива, но не можем тестировать скорость библиотек, использующих DOM API, объекты которого являются, по сути, теми же JS объектами?

По поводу вашего теста: я не понимаю, что вы тестируете. Хотя бы описание добавили.
>Почему мы можем тестировать, скажем, скорость сортировки массива, но не можем тестировать скорость библиотек, использующих DOM API, объекты которого являются, по сути, теми же JS объектами?

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

>По поводу вашего теста: я не понимаю, что вы тестируете. Хотя бы описание добавили.

Тестируется множество различных кэйсов, а не какой-то один вроде «добавление элемента в конец списка» как в вашем бэнчмарке. И тестируются библиотеки, которые используют один и тот же механизм для data binding'а, поддерживают те же самые оптимизации.

Библиотеки, использующие разные формы для дата байндинга будут иметь преимущества на одних кэйсах и проигрывать на других, например виртуальный дом имеет преимущество когда нужно просто быстро отрендерить дерево компонент, тк не нужно будет вешать всякие вотчеры как в случае с kvo или dirty-checking'ом. kvo имеет преимущество, когда нужно делать мелкие точечные апдэйты (например добавление элемента в конец списка).

Все эти бэнчмарки не имеют никакого смысла для общественности, которая не разбирается в том как работают различные библиотеки, их преимущества и недостатки.
Ну я, в любом случае, принимаю любую критику. Ваш коммент заставил повысить в приоритете эту фичу, позволяющую обогнать Vue в DBMON тесте (и Матрешка и Vue без track-by работают медленно, хотя первая — чуть быстрее).
в этом dbmon тесте есть проблема с тем что реализации, которые работают очень быстро, успевают сделать несколько дом апдэйтов до того как кадр начинает отрисовываться и из-за это fps на счётчике в правом нижнем углу будет показываться слишком завышеная цифра по сравнению с реальностью.

Так же у дом операций есть такая особенность, что если неправильно бэнчмаркать, то библиотеки, которые будут успевать сделать как можно больше циклов с тестом, время которого замеряется до того как кадр начнёт перерисовываться, будут показывать значительно лучшие результаты, тк оверхэд на дом операции будет гораздо ниже. Этой проблемой страдает мой vdom-benchmark, но я его уже давно не трогаяю, тк другие разработчики активно его используют, бэнчмарки на jsperf'е страдают такой же проблемой.

Вот насколько может отличаться скорость работы дом операций, если просто заставить после каждого теста делать перерисовку: jsfiddle.net/67jz79n2/2
Если я не ошибаюсь, если рендеринг происходит после оповещения о рендеринге, то на следующей итерации скорость рендеринга предыдущей итерации будет учтена, так как DOM — штука синхронная.
DOM операции синхронные, но например в хроме, на грязных элементах эти операции отрабатывают значительно быстрее до того как происходит reflow/paint итд. Поэтому если хочется увидеть цифры более близкие к реальности, то желательно заставлять браузер производить перерисовку перед каждой итерацией. Более быстрая библиотека от этого наврятли станет медленее, но зато результаты будут не в 5 раз быстрее, а где-нибудь в 2 раза, тк всё же дом операции являются узким местом.
А почему не запостите это сюда: mathieuancelin.github.io/js-repaint-perfs?
Лучше заставить автора этого бэнчмарка принимать ссылки на внешние сайты с различными реализациями, вместо того чтобы пихать всё в один репозиторий. Неудобно же собирать проекты, которые зависят от всяких инструментов типа babel'а. И если что-то обновлять, то постоянно дожидаться пока он примет пулл риквест.
Лучше заставить автора этого бэнчмарка принимать ссылки на внешние сайты с различными реализациями
Реализации самого бенчмарка тоже могут быть разными. Все бенчмарки в одном месте позволяют избежать жульничество.

И если что-то обновлять, то постоянно дожидаться пока он примет пулл риквест.
Ну можно и подождать. Мой риквест он почти сразу принял.
>Реализации самого бенчмарка тоже могут быть разными.

Там уже начались появляться костыли вроде: github.com/mathieuancelin/js-repaint-perfs/blob/0cef56a71658e4be2291a2b963331f42220ea498/ENV.js#L100

Так же если посмотреть на реализацию эмбера, там они тупо сами генерируют и модифицируют данные тем способом, которым принято в эмбере, а не то что в файле ENV.js.

В общем там итак полный бардак, не думаю что кто-то будет жульничать. Я например использую оригинальную версию этого бэнчмарка для отслеживания регрессий, не вижу смысла жульничать, всё равно легко проверить что происходит если у кого-то внезапно какой-то невероятно крутой результат. Да и гораздо сильнее можно жульничать в подобных бэнчмарках, если делать всякий изврат как например неявное кэширование всего в библиотеке Imba, утечки памяти гарантированы, зато побеждает кучу микробэнчмарков :)

И всё же, все реализации должны использовать те способы модификации данных, которые приняты в тестируемой библиотеке, а не то что в ENV.js.
Так же если посмотреть на реализацию эмбера, там они тупо сами генерируют и модифицируют данные тем способом, которым принято в эмбере, а не то что в файле ENV.js.
Если мы работаем с кастомным API, то тест вполне себе верный.
всё равно легко проверить что происходит если у кого-то внезапно какой-то невероятно крутой результат.
Для того, чтоб кто-то принял всерьез тест, разработчик теста должен обладать авторитетом или популярностью. Если «Вася Пупкин» сделает тест и разместит его у себя на сайте, я даже заглядывать в код не буду.
И всё же, все реализации должны использовать те способы модификации данных, которые приняты в тестируемой библиотеке, а не то что в ENV.js.
По воводу тестов, согласен.
>разработчик теста должен обладать авторитетом или популярностью

Там итак половина тестов написаны людьми, которые не обладают авторитетом или популярностью, а владелец репозитория просто не обладает достаточными знаниями обо всех библиотеках чтобы контролировать качество. Когда вы кинули пулл риквест на поломаный вариант с матрёшкой, он сразу же закоммитил его, ничего не проверяя. Так что нет никакого смысла держать всё в одном репозитории.
Со сломанным тестом это действительно косяк (скорее мой, так как я не запуллил изменения перед пулл-риквестом, а человек каким-то хитрым способом поменял генератор данных), но как показывает практика:
1. Никого не интересует, как сделан тест, кроме очень любопытных (их единицы).
2. Под «авторитетом» я не имею в виду качество кода разработчика или внимательность к деталям. Я имею в виду упоминаемость. В данном случае, чувак собрал все фреймворки, а ссылкой на тесты пользуется море людей. Кто эти тесты на самом деле написал, никого не интересует.
Лучше заставить автора этого бэнчмарка принимать ссылки на внешние сайты с различными реализациями
Тогда через пол-года половина тестов развалится, реп позволяет держать это как единый проект, чем он и является.
Тест (входные данные) могут меняться, какие-нибудь доработки, улучшения. Какие-то спорные моменты в issue.

владелец репозитория просто не обладает достаточными знаниями обо всех библиотеках чтобы контролировать качество
Сообщество может контролировать качество через issue и pull-request, влиять на 1 реп проще чем на 20 разных.

Имхо, плюсов больше.
Sign up to leave a comment.