Стартую фронтенд
6706
150
Just_a_fire сказал(а):↑Результаты могут разниться, но я сейчас выполнял их много раз на двух машинах, причём на ПК результаты разнятся, а на Маке foreach всегда быстрее
Конечно прикольные, ведь своих тестов ты так и не предоставил.
Даун как раз делает выводы на основании лишь 3-х тестов. А прогонять их нужно много раз.
Нажмите, чтобы раскрыть...а зачем их много раз проганять если ты увидишь что каждый раз результат разный))))
твои тесты это как ровнять силу героев в доте 1х1 на 6 слотах на речкеTill_Its_Gone сказал(а):↑Ух щас бы бенчмарки в ms
Нажмите, чтобы раскрыть...? не совсем понял что ты написал
pudgeRO сказал(а):↑а зачем их много раз проганять если ты увидишь что каждый раз результат разный))))
твои тесты это как ровнять силу героев в доте 1х1 на 6 слотах на речкеНажмите, чтобы раскрыть...Я тебе уже говорил, что на одной машине у меня результат всегда одинаковый. На другой почему-то иногда скачет. Но при если n увеличить, то цикл foreach везде становится медленнее.
И пока ты до сих пор не написал своих тестов, то все твои умствования ничего не стоят. Поэтому нет смысла продолжать с тобой разговор в этой теме, покуда ты не предоставишь свой код.
Just_a_fire сказал(а):↑Какой ещё оптимизирующий компилятор? Это тебе не GCC C++ с флагами оптимизации -O2 -O3.
Я специально для тебя ещё допишу код
let n = 10000000,
arrFor = Array(n).fill(0), arrForeach = Array(n).fill(0);console.time('for test');
let numFor = 0;
for (let i = 0; i < n; ++i) { arrFor[ i] = i; if (i%2) numFor += arrFor[ i ]; else numFor -= arrFor [ i ];}console.log(numFor); // эти строчки можно убрать, но скорость выполнения теста не изменитсяconsole.timeEnd('for test');
console.time('foreach test');
let numForeach = 0;
arrForeach.forEach((item, i) => {item = i;
if (i%2) numForeach += item; else numForeach -= item;
});
console.log(numForeach); // хотя все переменные "перестанут" использоваться
console.timeEnd('foreach test');
Циклы гоняются в любом случае с одинаковой скоростью, хотя мы можем даже не выводить в консоль numFor, numForeach
Мы также можем увеличить или уменьшить n, и скорость выполнения тестов увеличится и уменьшится соответственно. Что опять же свидетельствует о том, что циклы прогоняются.
Кстати, вопрос к тебе. Если цикл for быстрее, то почему при n = 100000 у меня цикл foreach выполняется быстрее (1.80 ms), чем цикл for (2.21 ms).
Вот ещё тебе пример синтетического теста, в котором тоже "мёртвый код". И подобных тестов немало. Их написавшие тоже не понимают, что этот код вообще не должен выполняться?
Работаю программистом уже больше 6 лет. И что-то мне подсказывает, что у тебя опыта в программировании будет меньше. И ты до сих пор не привёл примера кода, который по-твоему будет справедливо тестировать эти циклы.
Нажмите, чтобы раскрыть...я ничего не понял, но интересно. Скажи в кратце и понятно, что ты пытаешься доказать? Что for loop быстрее foreach функции?
Just_a_fire сказал(а):↑Я тебе уже говорил, что на одной машине у меня результат всегда одинаковый. На другой почему-то иногда скачет. Но при если n увеличить, то цикл foreach везде становится медленнее.
И пока ты до сих пор не написал своих тестов, то все твои умствования ничего не стоят. Поэтому нет смысла продолжать с тобой разговор в этой теме, покуда ты не предоставишь свой код.
Нажмите, чтобы раскрыть...ясно же если n большое фор будет быстрее форича вопрос то не в этом
а в том какой тест ты высрал в начале
который показывает ровным счетом ничего
даже видос тебе нашел про такие тесты который смотрел пару лет назад https://youtu.be/HPFARivHJRY
pudgeRO сказал(а):↑ясно же если n большое фор будет быстрее форича вопрос то не в этом
а в том какой тест ты высрал в начале
который показывает ровным счетом ничего
даже видос тебе нашел про такие тесты который смотрел пару лет назад https://youtu.be/HPFARivHJRY
Нажмите, чтобы раскрыть...если обернуть все то что он написал тоже в цикл на пару сотен тысяч, то тоже можно впринципе сравнение сделать) оно уже будет куда честнее
Till_Its_Gone сказал(а):↑я ничего не понял, но интересно. Скажи в кратце и понятно, что ты пытаешься доказать? Что for loop быстрее foreach функции?
Нажмите, чтобы раскрыть...Доказывать я ничего не пытался, т.к. сам не знал ответа. Лишь предложил ТСу протестировать самому. А этому челу не понравились мои тесты, он сказал, что оптимизатор должен выкинуть "мертвый код". Я ему доказал, что циклы в тестах прогоняются, но своих тестов он так и не предоставил.
Till_Its_Gone сказал(а):↑если обернуть все то что он написал тоже в цикл на пару сотен тысяч, то тоже можно впринципе сравнение сделать) оно уже будет куда честнее
Нажмите, чтобы раскрыть...первый тест? если да тогда в8 еще быстрее поймет что в циклах ничего не происходит и два масива никак не используются после циклов и еще быстрее их удалит да и сами циклы удалит тоже ведь в них ничего не происходит
будет просто тест того как быстро в8 поймет что у тебя весь код ничего не делает
Just_a_fire сказал(а):↑Доказывать я ничего не пытался, т.к. сам не знал ответа. Лишь предложил ТСу протестировать самому. А этому челу не понравились мои тесты, он сказал, что оптимизатор должен выкинуть "мертвый код". Я ему доказал, что циклы в тестах прогоняются, но своих тестов он так и не предоставил.
Нажмите, чтобы раскрыть...офк они прогоняются
но только первое время тоесть равно до того момента пока в8 не поймет что все что в циклах юзлесс как и сами циклы
pudgeRO сказал(а):↑первый тест? если да тогда в8 еще быстрее поймет что в циклах ничего не происходит и два масива никак не используются после циклов и еще быстрее их удалит да и сами циклы удалит тоже ведь в них ничего не происходит
будет просто тест того как быстро в8 поймет что у тебя весь код ничего не делает
Нажмите, чтобы раскрыть...Я про чистый js, без ваших v8. С v8 я думаю есть адекватные подходы тестирования)
Just_a_fire сказал(а):↑Доказывать я ничего не пытался, т.к. сам не знал ответа. Лишь предложил ТСу протестировать самому. А этому челу не понравились мои тесты, он сказал, что оптимизатор должен выкинуть "мертвый код". Я ему доказал, что циклы в тестах прогоняются, но своих тестов он так и не предоставил.
Нажмите, чтобы раскрыть...ну он типе намекнул тебе, что просто эти тесты бесполезны) а полезные тесты за 2 минуты не напишешь как бы)
Till_Its_Gone сказал(а):↑Я про чистый js, без ваших v8. С v8 я думаю есть адекватные подходы тестирования)
Нажмите, чтобы раскрыть...Так кто этот "чистый js" выполняет? Как раз V8 в хроме или NodeJS и выполняет. А него есть, конечно, свои оптимизации, но это не gcc C++ с флагами оптимизации.
Till_Its_Gone сказал(а):↑ну он вроде дал тебе идею того, что просто эти тесты бесполезны) а полезные тесты за 2 минуты не напишешь как бы)
Нажмите, чтобы раскрыть...У него было уже 2 дня, чтобы написать "полезные" тесты
Just_a_fire сказал(а):↑Так кто этот "чистый js" выполняет? Как раз V8 в хроме или NodeJS и выполняет. А него есть, конечно, свои оптимизации, но это не gcc C++ с флагами оптимизации.
Нажмите, чтобы раскрыть...я тебе скинул выше видео лучше посмотри и все вопросы отпадут
зачем это с gcc c++ сравнивать я хз
или ты пытаешься сказать что оптимизация есть только в gcc c++ с флагами оптимизации и больше ее нету нигде впринципе?
Till_Its_Gone сказал(а):↑а я забыл что v8 в браузере
у вас на работе занимаются таким тестированием?
Нажмите, чтобы раскрыть...Каким именно тестированием? Сравнивать for vs forEach vs map vs reduce? Обычно только ради подобных споров. Обычно в реальных приложениях нет таких больших объёмов данных, чтобы была ощутимая разница в производительности.
Just_a_fire сказал(а):↑Каким именно тестированием? Сравнивать for vs forEach vs map vs reduce? Обычно только ради подобных споров. Обычно в реальных приложениях нет таких больших объёмов данных, чтобы была ощутимая разница в производительности.
Нажмите, чтобы раскрыть...Ну я не конкретно про эти, а про тестирование тяжелых бизнес функций например)
Till_Its_Gone сказал(а):↑Ну я не конкретно про эти, а про тестирование тяжелых бизнес функций например)
Нажмите, чтобы раскрыть...В тяжёлых бизнес функциях будут использоваться далеко не только эти циклы. Поэтому я всё же подожду "правильных тестов", а он опять вокруг да около ходит и пишет мне, хотя я ему уже дал понять, что без его тестов не буду продолжать разговор с ним в этой теме.
Just_a_fire сказал(а):↑В тяжёлых бизнес функциях будут использоваться далеко не только эти циклы. Поэтому я всё же подожду "правильных тестов", а он опять вокруг да около ходит и пишет мне, хотя я ему уже дал понять, что без его тестов не буду продолжать разговор с ним в этой теме.
Нажмите, чтобы раскрыть...где я написал что я тебе напишу правильные тесты? скажешь?) а да точно нигде)
я тебе пишу милион раз о том что будет с твоими тестами а ты все в упор не видишь)))
давай тогда каждый останется при своем мнении чтоб ты спокойно мог дальше идти и писать такие прикольные тесты
pudgeRO сказал(а):↑ясно же если n большое фор будет быстрее форича вопрос то не в этом
а в том какой тест ты высрал в начале
который показывает ровным счетом ничего
даже видос тебе нашел про такие тесты который смотрел пару лет назад https://youtu.be/HPFARivHJRY
Нажмите, чтобы раскрыть...Я всё же посмотрел это видео на скорости 1.25 и у меня снова появился повод ответить, теперь по этому видео.
Само видео действительно в некоторой степени интересное, но ты посмотрел его когда-то давно, понял, что js-компиляторы достаточны умные и могут делать некоторые оптимизации, только в детали ты не вникнул. А просто услышал звон.
И к тестам, что я привёл, это имеет весьма отдалённое отношение.
Вначале ролика он говорил про аллокацию массива, но в моих тестах оба массива инициализируются 1 раз и до начала замеров.
Далее на 9:00 приводится довольно глупый бенчмарк, в котором строка инициалиризуется 1 раз, а потом в первом же прогоне она обрезается до нуля
str = str.slice(1);
и больше не инициализиуется
Далее он говорит на 12:50 про протяжку констант, что опять же не имеет отношения к моим тестам.
Но самое интересное происходит уже позже.
На 14:40:
ЧТО V8 НЕ УМЕЕТ УДАЛЯТЬ ЦИКЛ С "МЁРТВЫМ КОДОМ"
А что ты писал?
pudgeRO сказал(а):↑в твоем первом примере со временем комплитор увидит что ты не используешь свои масивы а значит и запихивать в них ничего не будет а еще позднее так вообще циклы проганять не будет
Нажмите, чтобы раскрыть...
Но самая вишенка на торте будет позже.
А перед этим я напомню твой "ответ" на мой пост, что движки JS это не gcc C++ с флагами оптимизации
pudgeRO сказал(а):↑с этого я вообще кекнул "Какой ещё оптимизирующий компилятор? Это тебе не GCC C++ с флагами оптимизации -O2 -O3."
Нажмите, чтобы раскрыть...На 17:24 докладчик из видео, что ты САМ же и кинул, говорит: "V8 НЕ УМЕЕТ ДЕЛАТЬ РАСКРУТКУ ЦИКЛА, ХОТЯ ВСЯКИЕ C++
C++
КОМПИЛЯТОРЫ ДЕЛАЮТ"
Ну что ж... ты действительно "кекнул", причём так, что аж подлива потекла.
Да и к чему это я. Ты даже не написал свой опыт в программировании, хотя теперь мне видно, что это уровень общения того, кто занимается этим пару лет, не больше. Забавно наблюдать.
И всё равно так и не сможешь написать "правильных тестов", даже если бы захотел. Не говоря уже о том, чтобы признать свою неправоту, а не делать хорошую мину при плохой игре.
sinkari сказал(а):↑Используете ли вы в своей работе БЭМ методологию? Аналогичный вопрос про css гриды.
Нажмите, чтобы раскрыть...БЭМ нужен в чистом html/css, но во фреймворках CSS модульный, поэтому и без него все ОК. В доке БЭМ даже есть статья "БЭМ в React", в которой объясняют, как можно использовать БЭМ вместе с модульным CSS, потому что использовать его там в чистом виде не особо нужно, потому что БЭМ нужен для того, чтобы делать переиспользуемый css код. В React переиспользуется не css код, а компоненты
Гриды крутые, но в целом юзлес. По очевидным причинам:
1. Они сложнее, потому что работают в две оси сразу и многое нужно запоминать, чтобы нормально все выравнивать. Во флексах у тебя элементы выстраиваются только по главной оси и для этого выравнивания есть 2.5 свойства, которые легко понять. Возможно, дело привычки, не знаю
2. Гриды не поддерживаются автодополнением Emmet. Уже 3 года висит issue в их github, но движений 0. Без этого писать код просто нереально напряжно
3. Гриды не поддерживаются самым популярным фреймворком, который позволяет с помощью веб технологий писать мобильные приложений, - react native. Там опять же только флексы
4. Как мне кажется, всратая структура внутри кода. У тебя внутри одного тега может быть 6 идущих подряд тегов, но с гридом это будет два столбца по 3 элемента. Во флексах такое невозможно. Тебе придется сделать внутри этого тега еще два тега-обертки, внутри которых будет три элемента из-за того, что флексы работают только по одной оси. По этой причине читать код с флексами просто проще
Учитывая хотя бы это, использовать гриды бессмысленно
Ramdesu сказал(а):↑БЭМ нужен в чистом html/css, но во фреймворках CSS модульный, поэтому и без него все ОК. В доке БЭМ даже есть статья "БЭМ в React", в которой объясняют, как можно использовать БЭМ вместе с модульным CSS, потому что использовать его там в чистом виде не особо нужно, потому что БЭМ нужен для того, чтобы делать переиспользуемый css код. В React переиспользуется не css код, а компоненты
Гриды крутые, но в целом юзлес. По очевидным причинам:
1. Они сложнее, потому что работают в две оси сразу и многое нужно запоминать, чтобы нормально все выравнивать. Во флексах у тебя элементы выстраиваются только по главной оси и для этого выравнивания есть 2.5 свойства, которые легко понять. Возможно, дело привычки, не знаю
2. Гриды не поддерживаются автодополнением Emmet. Уже 3 года висит issue в их github, но движений 0. Без этого писать код просто нереально напряжно
3. Гриды не поддерживаются самым популярным фреймворком, который позволяет с помощью веб технологий писать мобильные приложений, - react native. Там опять же только флексы
4. Как мне кажется, всратая структура внутри кода. У тебя внутри одного тега может быть 6 идущих подряд тегов, но с гридом это будет два столбца по 3 элемента. Во флексах такое невозможно. Тебе придется сделать внутри этого тега еще два тега-обертки, внутри которых будет три элемента из-за того, что флексы работают только по одной оси. По этой причине читать код с флексами просто проще
Учитывая хотя бы это, использовать гриды бессмысленно
Нажмите, чтобы раскрыть...Понял, спасибо
Ramdesu сказал(а):↑БЭМ нужен в чистом html/css, но во фреймворках CSS модульный, поэтому и без него все ОК. В доке БЭМ даже есть статья "БЭМ в React", в которой объясняют, как можно использовать БЭМ вместе с модульным CSS, потому что использовать его там в чистом виде не особо нужно, потому что БЭМ нужен для того, чтобы делать переиспользуемый css код. В React переиспользуется не css код, а компоненты
Гриды крутые, но в целом юзлес. По очевидным причинам:
1. Они сложнее, потому что работают в две оси сразу и многое нужно запоминать, чтобы нормально все выравнивать. Во флексах у тебя элементы выстраиваются только по главной оси и для этого выравнивания есть 2.5 свойства, которые легко понять. Возможно, дело привычки, не знаю
2. Гриды не поддерживаются автодополнением Emmet. Уже 3 года висит issue в их github, но движений 0. Без этого писать код просто нереально напряжно
3. Гриды не поддерживаются самым популярным фреймворком, который позволяет с помощью веб технологий писать мобильные приложений, - react native. Там опять же только флексы
4. Как мне кажется, всратая структура внутри кода. У тебя внутри одного тега может быть 6 идущих подряд тегов, но с гридом это будет два столбца по 3 элемента. Во флексах такое невозможно. Тебе придется сделать внутри этого тега еще два тега-обертки, внутри которых будет три элемента из-за того, что флексы работают только по одной оси. По этой причине читать код с флексами просто проще
Учитывая хотя бы это, использовать гриды бессмысленно
Нажмите, чтобы раскрыть...что насчет этой штуки?
https://styled-components.com/
Till_Its_Gone сказал(а):↑что насчет этой штуки?
https://styled-components.com/Нажмите, чтобы раскрыть...В связке с этой штукой https://styled-system.com/ очень даже неплохо получается
Тема закрыта
-
ЗаголовокОтветов ПросмотровПоследнее сообщение
-
Сообщений:11
Просмотров:15
-
Сообщений:10
Просмотров:10
-
Сообщений:3
Просмотров:3
-
Сообщений:4
Просмотров:5
-
Сообщений:22
Просмотров:28