Программирование[11]

Сортируют мапой только полные долбоебы. Goldrobot - без обид. Ты все-таки не настоящий айтишник.

Grohuf написал 1 минуту назад:

Сортируют мапой только полные долбоебы. Goldrobot - без обид. Ты все-таки не настоящий айтишник.

Расскажи что бы ты использовал и как?

Я всегда рад новым знаниям

GoldRobot написал 1 минуту назад:

Grohuf написал 4 минуты назад:

Сортируют мапой только полные долбоебы. Goldrobot - без обид. Ты все-таки не настоящий айтишник.

Расскажи что бы ты использовал и как?

Я всегда рад новым знаниям

Лнгчайшая 

Сортирует Array.prototype.sort

Вы чё, пацаны

`std::map` is slowest way in C++ to find something in `O(log(n))`
For example, it is slower then `std::sort + std::binary_search` 6 times

Вообще, зависит от частоты вставки в контейнер и требований к производительности. Если нужно держать небольшой контейнер, который постоянно меняется, то можно и std::map. Но вообще у новичков часто есть желание использовать std::map только для сортировки, для чего он неэффективен.

besteady написал 2 минуты назад:

`std::map` is slowest way in C++ to find something in `O(log(n))`
For example, it is slower then `std::sort + std::binary_search` 6 times

Ну это понятно, что если нагрузка большая, то надо пилить индекс по аналогии с базами данных. Но часто таких требований к производительности нет.

Grohuf написал 6 минут назад:

Если нужно держать небольшой контейнер, который постоянно меняется, то можно и std::map.

Так дуит и написал "вести список".

GoldRobot написал 2 минуты назад:

Grohuf написал 10 минут назад:

Если нужно держать небольшой контейнер, который постоянно меняется, то можно и std::map.

Так дуит и написал "вести список".

И что? Это должно мешать мне тебя подъебать?

Справедливо

Just.Doit написал 1 час назад:

например типа вести список, пофильтрованный и отсортированный по нескольким полям?

Если список бесконечно большой то имеет смысл делать инфинити скроллинг какой-нибудь + сортировку на беке с пагинацией. 

А если список маленький то сомневаюсь что отбитая фронтэндмакака напишет код факториальной сложности. 

besteady написал 36 минут назад:

`std::map` is slowest way in C++ to find something in `O(log(n))`
For example, it is slower then `std::sort + std::binary_search` 6 times

Это если использовать std::map::find()? Это же вроде атавизм, есть unordered_map с доступом в O(1). Если нужна сортировка офк только мануально отсортированный vector.

У нас используется https://en.cppreference.com/w/cpp/header/flat_map (своя реализация, офк)

13uRn1nG написал 12 минут назад:

есть unordered_map с доступом в O(1)

хэшмэп из std не рекомендуется использовать

Grohuf написал 19 минут назад:

У нас используется https://en.cppreference.com/w/cpp/header/flat_map (своя реализация, офк)

13uRn1nG написал 33 минуты назад:

есть unordered_map с доступом в O(1)

хэшмэп из std не рекомендуется использовать

хуево реализована? я юзаю обычно мапы из буста

13uRn1nG написал 1 минуту назад:

хуево реализована? я юзаю обычно мапы из буста

Для того, чтобы итераторы работали стандартным образом для библиотеки std, там реализация на списках. Такая реализация сильно медленней, чем реализация, сделанная только на массиве. Собственно, она медленная по той же причине, что и std::map - данные хранятся не последовательно в куче, что снижает эффективность кэширования.

Zellar написал 5 часов назад:

 

 

@suez Я вот видел на react скоро бэк можно будет хуячить. Что думаешь по этому поводу? Nest.js идет нахуй?

 

Нахуй он сможет пойти только если твои бекендеры захотят писать свой код в одном репо с фронт макаками. Плюс там куча гемора в плане архитектуры и безопасности. Я бы не стал сравнивать полноценный бэкенд с кучей апи (которые могут юзаться пачкой разных апп и сервисов), с какой-то хуйней где ты можешь просто что-то отрендерить на бэкенде.

Сейчас это в основном юзабельно чтобы делать SSR без hydration, то есть собрал данные на бэке, отрендерил тонкий фронт и послал немного жса который нужен для динамики, без надобности дублировать всё то, что было заюзано при SSR, как это делается в том же дефолтном nextjs.

Kant написал 2 часа назад:

самое главное, что если на фронте в принципе оказалось количество данных чтобы дефолтная сортировка (предполагается хотя бы N^2) не справилась за то же время что и любая другая, то обосрался бэк

 

хотя в бытие ВЕЛИКОГО ГРАФКЛА, где долбоебы дают фронту тащить всё что ему вздумается, вместо того, что ему надо, может у даунов такое и случается

хуй знает о чём речь идёт... обычно пагинация/infinite scroll с query limit=LIMIT. Один хуй фронт должен отображать контент по viewport, остальное какбы нахуй не надо. Скелетон или спиннер въебал на триггер фетча новой даты.
Ну жизнь не идеальна, и да бывает ты собираешь всю инфу о вендорах у себя на фронте. Ну хуй знает, нормализация есть для таких вещей. Доступ по ключу за константное время. И асинхронно считаешь свою ебучую дату, в очередях микро/макро задач. Или я нихуя не понял, о чем вообще диалог?
 
ну да бек уже сортировку посчитал и тебе вернул.

У вас тут пиздец наркомания какая-та обсуждается, кек.

Во первых на фронте никто сортировки свои не пишет, юзается дефолтный сорт метод у массива, который под капотом оптимизирован и вылизан прям пиздец как.

Во вторых если ты планируешь посылать на фронт данные с сотнями тысяч итемов в массивах, чтобы их потом как-то сортировать/фильтровать, то у тебя проблемы с общей архитектурой наверное, ибо фронт вообще не должен такой хуйней заниматься. А если речь идет о нескольких тысячах элементов, то там всегда ботлнеком будет рендеринг (в частности DOM и внутренности фронт-либ типа реактов). В итоге большую часть времени ты будешь ебаться с тем как избегать массовых ре-рендеров, как избегать рекомпиляции стилей если юзается ебучий css-in-js и всё в этом духе (что в 95% случаев будет "фикситься" с помощью виртуализации, что является универсальным костылем для любого современного UI с кучей элементов).

suez написал 19 минут назад:

что в 95% случаев будет "фикситься" с помощью виртуализации, что является универсальным костылем для любого современного UI с кучей элементов

ну а для того чтобы этим заниматься не нужно знать основы алгоритмов и структур данных?

или одни надежды что кто-то поумнее это сделал и можно пользоваться фреймворком?

Just.Doit написал Только что:

suez написал 20 минут назад:

что в 95% случаев будет "фикситься" с помощью виртуализации, что является универсальным костылем для любого современного UI с кучей элементов

ну а для того чтобы этим заниматься не нужно знать основы алгоритмов и структур данных?

или одни надежды что кто-то поумнее это сделал и можно пользоваться фреймворком?

 

 

По умолчанию будешь юзать популярную либу (коих дохуя), и если она по каким-то причинам недостаточно хороша, тогда уже можно идти пилить свой велосипед. Но для этого надо иметь прям реально уникальные и "крутые" проблемы, до которых еще надо дорасти.

Вот хороший пример - https://www.atlassian.com/engineering/rendering-like-butter-a-confluence-whiteboards-story (как конфулюенс челики запилили свой webgl рендерер и стейт-либу для вайтборда с неебическим перформансом).

Собственно большинство рандомных калек никогда не окажется в позиции где им надо будет пилить что-то подобное, где существующие либы не достаточно хороши.