-
Сообщений
19 413 -
Зарегистрирован
-
Посещение
-
Дней в лидерах
5 -
Время онлайн
171д 6ч 23м 2с
-
ShadesOfGrey понравился пост в теме: Программирование[11]
-
kve1 понравился пост в теме: Программирование[11]
-
Olololnet понравился пост в теме: Программирование[11]
-
Grohuf понравился пост в теме: Программирование[11]
-
Это за успешный ребейз на ремоут хромиума? Получил утку с ножом
-
Drakonian понравился пост в теме: Программирование[11]
-
Тимлид это линейный менеджер. Низшая ветвь в менеджерской иерархии. Это как ефрейтор в армии, как козлы на зоне. Над тобой стоят управленцы, рядом с тобой корпоративные рабы (как и ты) управленцев интересует как рабы хуячат, и ты являешься их глазами и ушами, а зачастую и жопой куда можно пнуть юнит, чтобы работал лучше. На этой роли имеет смысл сидеть тогда, когда либо есть какая-то перспектива двинуться вверх по лестнице, и иметь своих тимлидов. Либо команда нормально перформит и за это дают бабки. Но если у тебя в команде дауны, а над тобой дохуя инициативных, то будет больно. Как правило у Лида-лидов один начальник, а у тебя их будет куча, всякие деливери менеджеры, ХРы и прочие будут приходить и требовать тащить команду в разные стороны как лебедь рак да щука. Мне было бы тяжело ещё и из того, что я живу по принципу - хочешь сделать хорошо, сделай сам. Не получается у меня делегировать задачи. Хочется все время держать руку на пульсе.
-
scarppy понравился пост в теме: Программирование[11]
-
Так это вроде стандартный кейс, делают тим-лидом, через пол года часть говорит ну нахуй
-
А ну получается в сисярпе для пересечения создаются хэшсеты под капотом? Классно, вот бы не создавать хэшсеты по итератору коллекции которая уже и так хэшсет Вообще пересечение можно трактовать по разному. С учетом дубликатов или только уникальные значения например. Мой оригинальный тейк был про list.removeAll(collection) в java Как реализовано пересечение в сисярпе меня не ебет. Но добавлю следующее. С точки зрении асимптотической сложности func() { for(1 .. n) { /*O(1) operations*/ } for(1 .. n) { /*O(1) operations*/ } for(1 .. n) { /*O(1) operations*/ } } и func() { for(1 .. n) { /*O(1) operations*/ } } Эквивалентны O(n) но с моей точки зрения, в общем случае долбоебизм решать алгоритм первым способом, если он без каких-либо трейдофов может быть решен вторым. Хотя опять же, тут могут быть нюансы, где func() { for(1 .. n) { /*O(1) SIMD code*/ } for(1 .. n) { /*O(1) SIMD code*/ } for(1 .. n) { /*O(1) SIMD code*/ } } предпочтительнее func() { for(1 .. n) { /*O(1) non-SIMD code*/ } }
-
Vova понравился пост в теме: Программирование[11]
-
А ты про какие хеш-сеты? На цепочках или на открытой адресации? С множественным хэшированием? А может про вероятностные? У тебя лист может быть задизайнен всратее сета. А какой-нибудь EnumSet может быть на битовой маске, где пересечение находится битовым &, тупой уебан
-
@grok это правда? Нет, это неправда. В общем случае пересечение двух массивов не быстрее пересечения двух сетов. Наоборот — пересечение сетов почти всегда намного быстрее. Когда массивы теоретически могут выиграть Только в очень специфических случаях: Массивы уже отсортированы → можно сделать O(n + m) двумя указателями без доп. памяти. Элементы — только маленькие целые числа (0..1000), и можно использовать битовые массивы или счётчики. Объёмы данных совсем крошечные (десятки элементов) — тогда константы перевешивают асимптотику. Нужно сохранить порядок и дубликаты из первого массива, а превращение в set их уничтожит. Но в 99 % обычных задач (особенно когда массивы содержат строки, объекты, большие числа, UUID и т.д. — превращение в set и пересечение через него будет на порядки быстрее. А ты знаешь, как устроены хэш-сеты? Неа, расскажи пожалуйста
-
Нахуя мне смотреть имплементацию, если метод работает с ИТЕРАТОРАМИ блять. В java collectionA.removeAll(collectionB) вызывает contains() на collectionB который для хэшсетов O(1) Пройти да, проверить есть ли элемент в хэш-сете - O(1) епта
-
Какая разница какой язык, если у тебя пересечение двух листов это O(n*m) В то время как Пересечение двух сетов это O(n), если ты используешь правильный алгоритм. Проходишь по элементам одного сета за N и вызываешь O(1) contains на другом. >а шарп, где просто есть Except/Intersect Intersect<TSource>(IEnumerable<TSource>, IEnumerable<TSource>) Ну и говно, получается оно всегда использует итерацию по коллекциям, цикл в цикле. Похуй что у тебя, лист или сет. Охуеть конечно нормальная манипуляция Даже у листов пересечение можно найти быстрее чем за O(n*m) если их отсортировать, получается O(n log n + O m log m) но в шарпе мыслят иначе , так что хавай сложность близкую к квадратичной
-
Индусы пишут хуевый не сопровождаемый код. Плюс кто-то же должен оркестрировать индусов.
-
Бизнесу не поебать сколько это стоит бабок и сколько времени будет разрабатываться фича.
-
@Benchmark public boolean listRemoveList(Blackhole bh) { boolean r = listA.removeAll(listB); bh.consume(r); return r; } @Benchmark public boolean listRemoveSet(Blackhole bh) { HashSet<UUID> hashSet = new HashSet<>(listB); boolean r = listA.removeAll(hashSet); bh.consume(r); return r; } Померял на таком бенчмарке Benchmark (sizeA) (sizeB) Mode Cnt Score Error Units ContainsAllBenchmark.listRemoveList 1 1 avgt 5 0,006 � 0,001 us/op ContainsAllBenchmark.listRemoveList 1 10 avgt 5 0,010 � 0,001 us/op ContainsAllBenchmark.listRemoveList 1 100 avgt 5 0,064 � 0,003 us/op ContainsAllBenchmark.listRemoveList 10 1 avgt 5 0,022 � 0,002 us/op ContainsAllBenchmark.listRemoveList 10 10 avgt 5 0,048 � 0,002 us/op ContainsAllBenchmark.listRemoveList 10 100 avgt 5 0,065 � 0,002 us/op ContainsAllBenchmark.listRemoveList 100 1 avgt 5 0,211 � 0,003 us/op ContainsAllBenchmark.listRemoveList 100 10 avgt 5 0,703 � 0,054 us/op ContainsAllBenchmark.listRemoveList 100 100 avgt 5 3,708 � 0,072 us/op ContainsAllBenchmark.listRemoveSet 1 1 avgt 5 0,029 � 0,001 us/op ContainsAllBenchmark.listRemoveSet 1 10 avgt 5 0,123 � 0,008 us/op ContainsAllBenchmark.listRemoveSet 1 100 avgt 5 1,202 � 0,051 us/op ContainsAllBenchmark.listRemoveSet 10 1 avgt 5 0,071 � 0,005 us/op ContainsAllBenchmark.listRemoveSet 10 10 avgt 5 0,150 � 0,006 us/op ContainsAllBenchmark.listRemoveSet 10 100 avgt 5 1,185 � 0,037 us/op ContainsAllBenchmark.listRemoveSet 100 1 avgt 5 0,496 � 0,023 us/op ContainsAllBenchmark.listRemoveSet 100 10 avgt 5 0,606 � 0,034 us/op ContainsAllBenchmark.listRemoveSet 100 100 avgt 5 1,553 � 0,202 us/op Считаю что все правильно сделал что топил за обернуть в хэшсет. Во-превых в реальном коде хэш сет потом кучу раз переиспользуется, в бенчмарке я тестирую в том числе создание сета. Во-вторых, это лучше отражает семантику коллекции. На containsAll цифры конечно другие, но не отменяет факта что дуит хуйню несет, а пытаться заигрывать с кодом для дружбы с компиляторами черевато проблемами.
-
без деталей не понятно не долбаеб ли ты более лучшая асимптотика может давать худший перформанс в частных случаях особенно на небольших значениях и с jit какие там размеры листов? Че блять, че ты несешь? Какие нахуй jit и частные случаи? Ты про premature optimization слышал? А ну давай частный случай, где listA containsAll listB дает лучшую производительность. O(n+m) хуже чем O(n*m) только если M блять равна 1. Это тебе чисто из математики. А вот какие там волшебные оптимизации у JIT ты знаешь, а, мудень? Ты понимаешь что containsAll что на сете что на листе вызывает equals, он блять не векторизируется. Это блять не сравнение примитивов. Ебаный долбоеб наделяющий JIT какими-то волшебными свойствами кроме эскейп анализа, инлайна и бранч предикшонов . Давай JMH в руки и принеси сюда пример. Конченый дебил блять. И знаешь что я тебе скажу, долбоящер. Даже если там блять listB в один ебучий элемент, то JIT прекрасно заинлайнит и listB -> hashSetB -> containsAll в listA containsElement. Ебать, как же с тобой тяжело наверно работать душный и некомпетентный даун. Ебучий даун блять, лучшее что ты можешь сделать для JIT - писать асимптотически-корректный код. Если у тебя блять listB состоит из уникальных элементов, но он протобафом генерится как лист просто потому что в ПРОТОБАФЕ БЛЯТЬ НЕТ СЕТОВ, и ты делаешь listA containsAll listB, то ты ебучий долбоеб. Не надо тут выдумывать с обосранными штанами какие-то одолжения для JIT блять. Кстати, добавлю уточнение, там был не containsAll а removeAll, что сути не сильно меняет
-
Ну по факту напихали. Если ты видя цикл в цикле не можешь докумекать это n*n, n*m или n на константу (может вложенный цикл это цикл по алфавиту например) то ты реально проседаешь по хардам которые в современном мире нужны не только для байпаса душных собесов, но и в работе. на днях ревьюил МР чела, там list.containsAll(anotherList) я ему конечно тыкнул что у тебя тут асимптотика o(n*m) переделай в линейную
-
Index понравился пост в теме: Программирование[11]
-
Как писал один чувак в своем тг канале И вот реально для прототипирования платформенных задач, интеграций эта хуйня очень хороша. Можно в один промпт попросить поднять сервис настроить метрики дашборды алерты интеграции трассировки прочую хуйню. А самому уже писать бизнес-логику. И собственно где тут СТАЖЕРСКИЙ скоуп задач? Стажер будет это пол года делать и потом занесет себе на пол страницы CV в достижения как он все поднял и настроил. Обычно стажерам как раз дают в уже всем готовом скоупе писать как раз какую-то минорную бизнес-логику и обмазывать это все тестами.
-
scarppy понравился пост в теме: Программирование[11]
-
sB.Raven понравился пост в теме: Программирование[11]
-
Ну резать собаку ножом в шею как минимум сомнительно. У ножа никакое останавливающее действие. Когда он её пырнул собака и так в целом была на похуях и убежала себе даже не поджав хвост, точно так же можно было и уебать ногой/вообще ничего не делать. Ну а была бы собака под адреналином, её бы это тоже не остановило бы. Вот и спрашивается, нахуя? Понятно что для МУЖИКА С ЯЙЦАМИ нож это как-бы более статусно чем девчачий перцовый балончик. Но перцовый балончик позволит тебе не сесть на бутылку, особенно если ты Степашка.
