10.06.2022, 16:54
|
Интересующийся
|
|
Регистрация: 30.10.2020
Сообщений: 14
|
|
Почит философский вопрос о производительности
Всем привет.
Есть такой вопрос.
Есть массив юзеров, их может быть много, 10К, 20К, 30К а может и 100К.
Их нужно перебрать и посчитать для графиков пол юзера, сколько по годам, семейный статус, еще что то может быть.
это не проблема, перебор циклом, все дела, считаем.
Это можно сделать одним циклом, в одном методе, а можно сделать что бы каждый метод считал свое, пол, сем. положение, возраст, но тогда получается что будет три цикла. И еще третий вариант - добавить четвертый метод с циклом и и три метода считают каждое свое.
Для кода конечно хорошо если разделить на три метода, но тогда порождаются циклы, а 3 способ = лишний метод.
Вопрос в следующем - стоит ли вообще в моем случае парится за кол-во циклов, при условии что в циклах ничего сложного кроме if не будет, или все таки если 100К юзеров то будет тяжко?
|
|
10.06.2022, 17:24
|
Интересующийся
|
|
Регистрация: 30.10.2020
Сообщений: 14
|
|
Rise,
Это приходит с сервера на фронт. Фронт на ангуляре.
Может про 100К записей погорячился, там не все записи тянутся, а есть выборка и за период и по ключевым словам. Но в теории как бы может быть и 100К.
|
|
10.06.2022, 18:10
|
Профессор
|
|
Регистрация: 04.12.2012
Сообщений: 3,794
|
|
orloff, а сервер сразу не может вернуть нужные данные, чтобы их не пришлось на клиенте обрабатывать?
100к записей гонять с сервера на клиент только для того, чтобы клиент что-то там посчитал из этих записей - несколько нерационально.
|
|
10.06.2022, 18:25
|
|
Профессор
|
|
Регистрация: 03.02.2020
Сообщений: 2,750
|
|
Nexus, а ведь бывает так, что результаты расчета более объемны, чем исходные данные.
orloff
По мне так 5 циклов с простыми телами занимают не сильно больше времени, чем один цикл со сложным телом.
К тому же проще будет если "еще что то может быть."
Третий способ мне совсем не нравится.
Во-первых не очень понятно про методы чего вы пишите? Что является объектом у которого эти методы? Если это набор пользователей, то логичнее иметь у него методы обработки именно набора, а не единичного элемента.
Во-вторых вызовы функций (методов) в цикле сильнее отразятся на эффективности, чем несколько простых циклов.
Ну и если, действительно, обсчет совсем простой, то время получения данных с сервера будет существеннее больше, чем расчет любым из способов.
Последний раз редактировалось voraa, 10.06.2022 в 18:32.
|
|
10.06.2022, 19:14
|
Интересующийся
|
|
Регистрация: 30.10.2020
Сообщений: 14
|
|
voraa, Nexus,
Там дело в том что этот список юзеров будет выводится в таблице без пагинации, это конечно тоже лажа, но пока так. Так что и расчеты делаются на фронте так как данные и так и так нужно будет получать все. А если чет поменяется, то просто мой код можно будет на бек перенести копипастом )
Пожалуй да, лучше каждый метод со своим циклом, который считает свои данные.
Я почему вообще спрашиваю периодически попадаются такие моменты когда рука так и тянется все сделать в одном цикле, но тогда код страдает - все обработки тулить в одну кучу, потом и с бутылкой Джека не разберешься ) А так то у меня с самого начала такой бзик есть что бы минимум кода, минимум циклов, минимум переменных, минимум событий, минимум классов. Но если так разобраться там ангуляр под капотом хранит и обрабатывает такой массив данных и событий что ванилой за месяц сколько событий и служебных данных не наваляешь )))
|
|
|
|