Комментарии 34
del
А что с in? Вы не замеряли?
Нет, не замерял, ни в рамках подготовки статьи, ни в рамках разработки библиотеки.
Функционал просто стараюсь наращивать итерациями — когда время есть:)
Мы пишем код для машин или для людей?
Я согласен, что местами в этом есть необходимость. В большинстве же случаев вполне хватает нативных конструкций.
Но, в моем случае, я писал библиотеку, и, следовательно, интерфейсы я пишу для людей, а реализации для машины. И, думаю, если реализация окажется медленной, то Вас эстетическая сторона кода вообще интересовать не станет — вы просто выберете библиотеку побыстрее:)
Я не по поводу библиотеки)
Я писал касательно не использовать map, reduce и filter )
Ваша библиотека по результатам бенчмаркинга вызвала интерес у меня)
Как видите, на массивах размером < 25k элементов вообще не стоит выбора что использовать — нативные методы обгоняют любые другие реализации.
Но если стоит вопрос о том, что отработать надо шустро, а элементов в массиве много, то лучше проверить наличие альтернатив:)
Да и я не призывал избегать map, filter и reduce, пост написан исключительно с целью предостеречь, мол «осторожно, может произойти и так»
Мой комментарий адресован Full-R
Я не пропагандирую начать создавать web на ассемблере вместо предназначенных для этого ООП языков и их обвязки, я за экологию и экономию заряда батареи не смотря на то, что вода уже кипит и ток мчится по проводам неперывно. Платим мы все равно ценой КВ в час.
Время чтения и понимания кода вы учитываете ?)
У меня свой собственный framework на архитектуре Kernel<Model<View и в данном случае обвязка интерфейса и беготня по циклам не относится к тому, что я бы хотел позволить разрабатывать кому-то на сахаре. Есть также более высокоуровневые функции для работы с ядром. Для бэкенда, например, все самое интересное начинается на API моделей, которые по сути транслируют в JOINы(для выборки) через ядерный компонент движка БД. Для frontend это, к примеру методы detach для event, которые по хэшу md5 элементов и приатаченых функций лопатят сотни HTML элементов. И там все на for потому, что это разумно для моего полностью динамического интерфейса и вам не надо понимать как это работает потому что API простое и удобное. Я написал анонс в песочницу, но меня пока не публикуют. Но вообще то, что торчит из ядра обычно уже есть сахар и обвязка более простая чем Kernel Parts — с читабельностью и осмысленностью API проблем нет, а код выполняется даже с подключением к БД на бэкенд, который создан по принципу SPL ценой 1Мб памяти и 0.003 секунды после кэширования на самом дешёвом Linux хостинге. Если анонс опубликуют — можем подискуссировать о подходах. Сейчас здесь не место — это территория автора статьи. Спасибо ему, кстати.
И, что более важно, в большинстве случаев речь о коллекциях до сотни элементов. 50млн — в 0.001% случаев, наверное. Не использовать более понятные конструкции в таком случае — неразумно.
Качественно написанный нативный код всегда быстрее качественно написанного кода для виртуальной машины. А утверждать превосходство вм кода сравнивая разные алгоритмы для вм с неизвестно каким нативным кодом дело бесполезное
моя реализация чуточку быстрее чем просто for, на котором она основанасразу возникают вопросы к тестированию и сомнения в целом
В любом случае, если Вы решите произвести свои замеры, то я с удовольствием бы ознакомился с вашими результатами — я за объективные данные.
Код не смотрел, но видимо где-то закралось кеширование или оптимизация. Но это не отменяет того, что используется for-конструкция, следовательно, не совсем корректно говорить, что она медленнее.
Можно ещё чуть чуть ускорить:
Оффтоп: Пожалуйста не используйте прозрачность на тексте. Это заставляет браузер текст растрировать. Из за этого у меня большая часть текста терялась при конвертации. Ну и на производительность прозрачность влияет.
Там прозрачность тексту нужна, чтобы выделение текста было видимо.
Я не о об этом:
[mol_textarea_edit] {
color: transparent;
}Это походу никак не влияет рендеринг по крайней мере пока текст не выделен.
А об этом:
[mol_text_type="code-punctuation"] {
opacity: .5;
}
[mol_theme="$mol_theme_light"], :root {
--mol_theme_text: rgba( 0 , 0 , 0 , .9 );
}Если тут убрать прозрачность то тогда текст при конвертации в XPS остаётся текстом.
С тестированием здесь всё в порядке, просто нативные методы ещё дырки в массивах учитывают (дополнительная операция in), вот и оказываются медленнее.
А средние выводил из межквартильного размаха, чтобы убрать самые быстрые и самые медленные выбросы.
Таким образом — статистика основанна на средних значениях.
Я потому и замерял все по 10 раз.
Это ничего не меняет. Если определенный прогон проходит определенные JIT-оптимизации, то 10 раз он тоже их будет проходить. Вы же не думаете, что на работу компилятора влияет фаза луны?
Лично я научился осторожно относиться к бенчмаркам JS еще во времена, когда JIT-компиляция только началась, и я собственными глазами на продовом коде увидел, как два очень-очень похожих по вычислительной сложности алгоритма отличались по производительности на два порядка. Просто потому, что на один из сразу же набрасывался компилятор, а на второй почему-то не набрасывался.
Чет сложно придумывается кейс даже для массивов из 50к элементов, разве что язык в этой точке уже немного не по назначению используется. Ну и это — как идея, почему бы вам в вашей библиотеке не проверять размер массива и не выбирать соответсвющую реализацию исходя из него, если вдруг 10кк сценарии таки имеют место быть.
В разных окружениях будут разные результаты: node, chrome, Firefox
Так же, разные (как ни странно) результаты будут в зависимости от того, что именно происходит внутри цикла — например, если вынести все операции в отдельную функцию
github.com/vzhou842/faster.js
Нативный — не значит быстрый. Обгоняем map, filter и reduce на больших массивах