Я писал безотносительно размера массивов и способов замера времени.
Сравнивать быстродействие надо на одинаковых сценариях. А то, что при использовании массива можно сценарий оптимизировать- ну этот сценарий можно, другой нельзя будет.
Т.е. если говорить об изначальном вопросе (что быстрее циклы или стрелки), то условия эксперимента не корректные. В первом случае автор прогнал 2 последовательных цикла, во втором-один. Вместо чистого эксперимента сделана оптимизация кода и сравнение с оригинальной версией.
На каком уровне права нарезать будете? На уровне каждого отдельного контрола со списком.
Ещё раз, выдумывать выход можно. Нарезать права, и т.п. Но предусмотреть все требования реального заказчика нельзя. Вы меня не услышали. Не надо пытаться ограничивать вариативность разработки.
Ну и плюс кто будет платить за создание и поддержание этих стандартов? Или ваши учёные бесплатно работать будут? И не надо писать про нулевую стоимость разработки, когда библиотеки уже созданы. Сами себя они не создадут. И поддерживать себя сами не будут.
Вы когда-нибудь сталкивались с иб в более-менее серьёзном бизнесе? Я с удовольствием посмотрю, как вы им будете объяснять, что возможность сохранить список, содержащий коммерческую тайну в файл-это оказывается стандарт такой.
Ну а если серьёзно, то что вы предлагаете-это ограничение вариативности разработки. Ну нельзя расписать до молочей все требования, которые в проектах возникают. И наука здесь абсолютно ни причем. Это никому не нужно, ни бизнесу, ни разработчикам, ни пользователям, которые это ви конечном счёте оплачивать будут.
Решаемая задача одна. Сценарий у автора как раз разный.
Одинаковый сценарий был бы например заполнение данных в 1 массиве через лямбду и через цикл.
Я писал безотносительно размера массивов и способов замера времени.
Сравнивать быстродействие надо на одинаковых сценариях. А то, что при использовании массива можно сценарий оптимизировать- ну этот сценарий можно, другой нельзя будет.
Т.е. если говорить об изначальном вопросе (что быстрее циклы или стрелки), то условия эксперимента не корректные. В первом случае автор прогнал 2 последовательных цикла, во втором-один. Вместо чистого эксперимента сделана оптимизация кода и сравнение с оригинальной версией.
На каком уровне права нарезать будете? На уровне каждого отдельного контрола со списком.
Ещё раз, выдумывать выход можно. Нарезать права, и т.п. Но предусмотреть все требования реального заказчика нельзя. Вы меня не услышали. Не надо пытаться ограничивать вариативность разработки.
Ну и плюс кто будет платить за создание и поддержание этих стандартов? Или ваши учёные бесплатно работать будут? И не надо писать про нулевую стоимость разработки, когда библиотеки уже созданы. Сами себя они не создадут. И поддерживать себя сами не будут.
Вы когда-нибудь сталкивались с иб в более-менее серьёзном бизнесе? Я с удовольствием посмотрю, как вы им будете объяснять, что возможность сохранить список, содержащий коммерческую тайну в файл-это оказывается стандарт такой.
Ну а если серьёзно, то что вы предлагаете-это ограничение вариативности разработки. Ну нельзя расписать до молочей все требования, которые в проектах возникают. И наука здесь абсолютно ни причем. Это никому не нужно, ни бизнесу, ни разработчикам, ни пользователям, которые это ви конечном счёте оплачивать будут.