Комментарии 59
У этих 3х абзацев ещё и черновой вариант был?! Чуствую все таки дождусь когда статьи на хобре в виде твитов появятся.
А причём тут структуры данных? Если бы я использовал List, то что-то изменилось бы в логике?
Вот видите, знать 2 структуры данных ещё лучше ;)
ЗЫ: автор конечно же молодец. Почти как дорожник, наконец заасфаальтировавший дырку в асфальте, и сэкономивший сотне автомобилистов ресурс ходовой.
Справедливости ради, проверка contains в List'e может занимать изрядное время. Насколько это критично зависит от количества и качества данных
ПС видимо автор Set таки и не знает, иначе бы не добавлял эту проверку
ПС видимо автор Set таки и не знает, иначе бы не добавлял эту проверку
А почему? Он ведь проверяет наличие uuid в uuids для того, чтобы определить, отправлять ли информацию, или она уже была ранее отправлена, а не для того, чтобы избежать повторного добавления данных в Set.
.contains() для
List: O(min(i, n-i))
Set: O(1)~
Если я правильно понял, комментарий в постскриптуме не относился к List, а был просто про Set.
Вы еще забыли константу перед сложностью, и для небольших размеров в десятки записей линейный поиск по вектору (я про С++, где вектор - это непрерываня область памяти; не знаю, как лист а iOS устроен) быстрее и выгоднее, чем любые сеты/мапы.
Теоретически да, но мне кажется там просто неправильный код. Вряд ли они отправляют все uuid каждый раз при добавлении одного элемента.
Потому что во многих языках у множеств операция add возвращает boolean, и скорее всего можно было написать вот так:
if uuids.add(uuid) {
logAnalytics(for: uuid)
}
Ещё бы понять что это вообще за язык, в хабах только Swift указан, но там у множества метода add нету.
А если бы просто сложил все в сет без проверки на наличие, и потом уже отправил весь полученный сет возможно сэкономил бы еще больше (особенно если там пакетная обработка возможна)
Внутри Set как правило хеш таблица.
А внутри list что?
Если только речь не идёт о PHP
В PHP и структуры данных-то такой нет
Но речь выше была о том, что массив в PHP — достаточно необычный тип данных, одновременно совмещающий в себе и линейный, и ассоциативный массивы.
Ну наверное поиск по списку был бы дольше. О(n) , против O(1) в среднем.
Да.
Видимо приходит много одинаковых событий, и они запихиваются в set, он по определению не хранит в себе одинаковых объектов, таким образом происходит дедупликация.
Если бы был list, то одинаковые события так бы и сыпались и сохранялись как и раньше, тк list позваляет хранить внутри себя одинаковые элементы.
я не согласен с автором, потому чт
наша группа копирайтеров всё ещё вычитывает черновой вариант комментария
Знание структур данных поможет оптимизировать код.
Для начала позволит создать работающий код.
P.S.
В больших продуктах каждая оптимизация умножается на миллионы/миллиарды пользователей.
И сколько же у нас МИЛЛИАРДОВ пользователей?
почему именно 22 000 $ , как считали?
Этот момент как раз не вызывает вопросов, если вкратце $22000 - виртуальные попугаи.
Компании с достаточно обширной инфраструктурой ведут мониторинг используемых ресурсов, как минимум сколько каждое приложение в данный момент потребляет CPU и сколько памяти, делается это как минимум для того, чтобы «сошедшее с ума» приложение которое внезапно начинает потреблять много ресурсов можно было прибить, чтобы оно не аффектило другие приложения.
Следующий шаг очень простой можно посчитать сколько то или иное приложение потребляет CPU/RAM в течении дня/месяца/года и раздать бюджеты командам разработчикам, чтобы они были заинтересованы в создании более эффективных приложений - сэкономить памяти в одном месте, чтобы потратить ее в другом.
Следующий шаг это введение единой метрики, когда минута процессорного времени получает какое-то значение в попугаях, так и мегабайт памяти ещё какое-то значение. Попугаи можно обозвать долларами, так выглядит более наглядно.
К CPU/RAM можно добавить и другие компоненты - жесткий диск, сеть. Тут уж что важно для компании и что можно посчитать.
Ну и походя к сути вопроса, после внедрения той фичи метрика показала падение использования ресурсов эквивалентного 22000 попугаев в год.
Если использовать для сбора аналитики какой-нибудь segment, то количество запросов будет равно количеству уплаченных денег.
Только ногами не пинайте, я не настоящий сварщик, но нельзя ли как-то последовательно пронумеровать элементы на экране числами от 0 и выше? Тогда для хранения информации о том, что аналитика по элементу отправлена, хватило бы битового вектора, где id элемента - это позиция бита в векторе. Думаю, что одного единственно int на экран хватило бы за глаза. Ну и пара битовых операций к нему. Быстрее просто некуда.
У разных пользователей могут показываться разные элементы на экране, поэтому нужны глобальные идентификаторы. Какие-нибудь A/B тесты проводят.
Так вроде это и сделано, у объектов вычисляются хэши. А что в функции logAnalytics мы не знаем, может там по уиду находится объект и отсылается все состояние.
когда-нибудь он освоит и эту структуру =)
Например если вы видели на экране “XYZ” 10 раз прокрутив контент вверх вниз несколько раз, то аналитика отправлялась 10 раз. Хоть 1 раза было достаточно.
Ну то есть раньше в аналитике были видны множественные прокрутки до конкретного контента, а теперь нет. Надеюсь, аналитики были в курсе изменений.
Вот вот, обычно аналитикам крайне важно, сколько раз и как было показано ключевое слово/фраза/картинка.
Чета тут не то...
Очень верное замечание. Такими темпами можно вообще аналитику удалить и сэкономить ещё больше непонятно как посчитанных денег.
Про $22 000 экономии в год немного смешно, явно один разработчик получает в год больше.
-Босс, я придумал как фирме экономить 2 тысячи баксов в месяц!
-Решил уволится?
Не, фикс, наверно полезный для Uber, но памятуя какие у них зарплаты вспоминается этот анекдот.
До кучи, писать в такой «лог» чревато потерей информации — представленный фрагмент кода просто отбрасывает ЛЮБЫЕ новые сообщения с тем же идентификатором.
Сто процентов , только хотел написать. Проблема явно в архитетуре , а это попытка замазать проблему. Ну а по поводу статьи , больше самопиар
Справедливости ради, там написано "дедупликация аналитики", а не "дедупликация UUID". Это не одно и тоже.
Да и по логике видно, что идёт проверка на наличие UUID, а не проверка на его уникальность.
Я правильно понял, что в конце графика бэкенд упал с ООМ?
Этот сет по-хорошему должен быть ограниченным по количеству LRU list
Проблема
Часто используемый скрин приложения отправлял impression аналитику при прокрутке экрана с дублированием. Например если вы видели на экране “XYZ” 10 раз прокрутив контент вверх вниз несколько раз, то аналитика отправлялась 10 раз. Хоть 1 раза было достаточно.
А с каких пор для аналитики это стала проблема? мне кажется это автор своим решением сделал проблему для аналитиков
Тот момент, когда комментарии читал намного дольше, чем статью.
Хотелось бы больше примеров не только с Set, потому что заголовок: "Почему программистам нужно знать структуры данных и как я сэкономил компании $22 000 в год", а не "Почему программисту важно знать структуру данных Set".
И про 22к долларов не понял, откуда взялась цифра?
Почему программистам нужно знать структуры данных и как я сэкономил компании $22 000 в год