Комментарии 20
Очень быстрое видео. Вы не оставляете время зрителю на то, что-бы посмотреть и оценить что именно происходит. Даже паузу поставить сложно в нужный момент.
Вы не сравнивали defineProperty с Proxy по скорости?
Сколько суммарно ушло времени на создание этого ролика?
Сколько суммарно ушло времени на создание этого ролика?
Нет, не сравнивал. Но, теоретически, defineProperty быстрее, так как в нем указывается какие свойства нужно «слушать». Proxy «слушает» все изменения (как и Object.observe, который выпиливают из спецификации).
Суммарно — могу сказать лишь примерно. Половина времени была затрачена на то, чтоб разобраться с Audacity и Kdenlive. Если брать только монтаж, то на половину ролика ушло 2 часа (т. е. примерно 4 часа на монтаж 6 минутного ролика). Сценарий, примеры, запись голоса, думаю, около 3 часов.
Суммарно — могу сказать лишь примерно. Половина времени была затрачена на то, чтоб разобраться с Audacity и Kdenlive. Если брать только монтаж, то на половину ролика ушло 2 часа (т. е. примерно 4 часа на монтаж 6 минутного ролика). Сценарий, примеры, запись голоса, думаю, около 3 часов.
Кстати, вы как-то просили добавить Матрешку в «местный бенчмарк». Вот он.
Спасибо.
Начал причесывать эти тесты и наткнулся на аномалию — в хроме рендеринг проседает до 80% на пустом месте, анализировал профайлеры и таймлайны, гуглил — ничего. Оказалось, это проседание зависит от первых двух выводимых символов: «mk»/«ng»/«vj» (кто бы мог подумать), и это воспроизводится систематический, я уже подобрал «оптимальные» символы. В FF это не воспроизводится — работает нормально. Сделаю всем тестам одинаковый текст, что-бы было по честному.
Начал причесывать эти тесты и наткнулся на аномалию — в хроме рендеринг проседает до 80% на пустом месте, анализировал профайлеры и таймлайны, гуглил — ничего. Оказалось, это проседание зависит от первых двух выводимых символов: «mk»/«ng»/«vj» (кто бы мог подумать), и это воспроизводится систематический, я уже подобрал «оптимальные» символы. В FF это не воспроизводится — работает нормально. Сделаю всем тестам одинаковый текст, что-бы было по честному.
Я немного сомневаюсь в этом тесте. Рендеринг (или серверный пререндеринг) большого количества элементов вызывает тормоза страницы, которые решаются костылями, типа этого. Может, сделаете многократную перерисовку меньшего числа элементов?
Просто мысли в слух: в идеале хотелось бы получить альтернативу jsperf, который объективно замеряет скорость операций. В jsperf я разочеровался после этого теста. Консольный тест с jsperf расходится в 450 раз!
Просто мысли в слух: в идеале хотелось бы получить альтернативу jsperf, который объективно замеряет скорость операций. В jsperf я разочеровался после этого теста. Консольный тест с jsperf расходится в 450 раз!
Я немного сомневаюсь в этом тесте.У всех тестов есть свои недостатки. Я кстати перетащил его на гитхаб.
Вот этот тест замеряет только перерисовку, а в «хабра» тесте есть ещё и первичное построение, что тоже важно.
Будет время — попробую сделать быструю перерисовку меньшего кол-ва, хотя у меня появилась проблема с Basis.js lahmatiy — в хроме почему-то не всегда учитывается время рендеренга, даже если несколько раз вызвать setTimeout, из-за этого он иногда выдает цифры ниже/лучше чем у vanilla js.
В jsperf я разочеровался после этого теста.JSperf вообще испортился — баги, кривые замеры, да ещё и редактировать не удобно.
Цифры basis.js ниже/лучше чем у vanilla, потому что vanilla решение написано не оптимально. А перепады в цифрах, скорей всего говорят об оптимизациях/деоптимизациях и каких-то подкапотных процессах браузера, которые оказывают достаточно сильное влияние.
vanilla решение написано не оптимальноНет, оно нормальное, их 2 варианта и один из них использует DocumentFragment, попробуйте написать более быстрое решение. Тем более 80% тратится не на построение DOM, а на рендеринг.
и каких-то подкапотных процессах браузераДа, я выше озвучил причину — не учитывается время рендеринга, если вы проанализируете Timeline, то видно что во всех тестах самые ресурсоемкие операции «Layout» и «Update Layer Tree» срабатывают до фиксации времени — что правильно, а в тесте «basis fill» иногда эти операции «проскакивают» за фиксацию времени, т.е. как раз самые тяжелые операции, которые создал basis, не зачитались в результате.
Можно конечно сделать setTimeout побольше (например 10), но это неправильный костыль. Кстати надо попробовать requestAnimationFrame, возможно это решит проблему.
Применил requestAnimationFrame, теперь вся* нагрузка отражается в операции «Layout», и цифры не «скачут».
А ссылку можно?
Вот, я её в комментах выше привел, правда она там не приметная.
vanilla решение написано не оптимально
Беру свои слова обратно. Там действительно все ок.
Только во втором решении не увидел, где используется DocumentFragment. Код обоих решений идентичен, за исключением одно цифры ;)
Отличная статья! Просто и доступно рассказано, вам удалось меня заинтересовать!
Спасибо!)
Спасибо!)
Матрешку иногда критикуют за способ, который был выбран для связывания данных и представления. Если быть точнее, у разработчиков вызывает вопросы метод bindNode и использование селектора вместо новомодных компонентов или описания логики прямо в HTML коде.
По такому же пути прошел (и «пришел» в смысле «докатился») WPF.
На практике многим уже приходится писать свой или грызть чужой велосипед, позволяющий в биндинге декларативно описывать логику (в смысле всяких трансформаций или арифметических выражений).
Иначе нужно будет плодить кучу конвертеров либо копипастить с незначительными изменениями куски кода в VM части (не знаю как слой «под UI» называется в терминах матрёшки, уж простите).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
(Архив) Matreshka.js — Три возможности