
Vasily
23.08.2017
12:34:18
Если уж мы про удаление
То лучше Hashset
Чем лист

Friedrich
23.08.2017
12:34:30
А чо вы делаете, народ?

Google

Friedrich
23.08.2017
12:34:38
Может, и правда персистентным вектором фигануть, а?
Правда, он мусорит при модификациях.

Vasily
23.08.2017
12:34:45
Ну я провожу диванную аналитику
Решения hlcup
от мейлрушечки

Vladimir
23.08.2017
12:35:22
потом его нужно замапить, ResizeArray по мне так отлично подходит
idlist -> map getEntityById

Vasily
23.08.2017
12:35:55
HashSet - та же последовательность

Vladimir
23.08.2017
12:36:00
на гетах нужно будет мапить на каждом третьем запросе

Vasily
23.08.2017
12:36:01
Тут ничего не поменяется

Friedrich
23.08.2017
12:36:04

Vladimir
23.08.2017
12:37:45

Vasily
23.08.2017
12:38:27

Google

Vladimir
23.08.2017
12:38:51
ну смотри у нас есть лист айдишек юзеров, на что ты предлагаешь поменять это?

Vasily
23.08.2017
12:38:57
Hashset

Vladimir
23.08.2017
12:39:12
что там будет ключом что значением?

Vasily
23.08.2017
12:39:26
Ты с Dictionary не путай
Разные вещи

Friedrich
23.08.2017
12:40:33
В F# есть стандартные множества какие-то.

Vasily
23.08.2017
12:40:45
Ну надо смотреть, что есть, да

Friedrich
23.08.2017
12:40:53
Хотя, вроде, они иммутабельные. Наверное, вам из BCL больше подойдут, там мутабельные.

Vasily
23.08.2017
12:41:10
HashSet<int> жеж

Vladimir
23.08.2017
12:42:28
пойду гуглить)

Vasily
23.08.2017
12:42:34
Давай
Кстати, онолитеги
Сколько у нас там операция удаления из листа? O(n)?

Ilya
23.08.2017
12:43:31
да

Friedrich
23.08.2017
12:43:33
Ну, типа да.
Из ResizeArray, кстати, тоже :)

Vasily
23.08.2017
12:43:50
А из хешсета O(1), как я понимаю

Friedrich
23.08.2017
12:43:51
(но это худший случай)

Vasily
23.08.2017
12:44:02
Хотя не

Ilya
23.08.2017
12:44:05
у рейсайзАррея это любой случай же

Google

Friedrich
23.08.2017
12:44:09
Нет.
Если из конца удалять, то будет быстро.

Vasily
23.08.2017
12:44:17
Там худший, когда все совпадают хеши
Если удалять по индексУ, то быстро

Friedrich
23.08.2017
12:44:53
А тебе надо по значению? Тогда медленно, ага.

Ilya
23.08.2017
12:44:54
https://msdn.microsoft.com/ru-ru/library/cd666k3e(v=vs.110).aspx

Vasily
23.08.2017
12:45:48
О, а у хешсета действительно О(1)
Не все я еще растерял на энтерпрайзных галерах
Хотя худший у хешсета все же O(n)
В определенном случае
Но это не наш вариант

Ilya
23.08.2017
12:48:25
Кстати, средняя скорость добавления n элементов в ResizeArray будет n, а вот в персистентный вектор по-прежнему NlogN

Vasily
23.08.2017
12:49:04
На самом деле там самые большие потери при десериализации скорее всего
Я имею в виду в решении для hlcup

Friedrich
23.08.2017
12:49:29
Там логарифм нестрашный, насколько я понимаю. На практике не очень заметное проседание, в пределах 10%.

Ilya
23.08.2017
12:49:52
ну обычно, там 32 основание делают, да.

Friedrich
23.08.2017
12:50:10
Но, да, утверждение в целом верное, вектор это не серебряная пуля.

Vasily
23.08.2017
12:50:24
Серебряных пуль вообще нет

Friedrich
23.08.2017
12:50:35
У него по сравнению с ResizeArray есть как преимущества, так и недостатки, всё честно :)

Vladimir
23.08.2017
12:51:32
я очень извиняюсь, не могу пока подискутировать, надо поработать, вечером вернусь)

Google

Evgeniy
23.08.2017
13:11:33
Подскажите, пожалуйста. Я правильно помню, что цепочки с Seq не очень быстро работают? Например, из кода:
|> Seq.map (fun key -> visits.[key])
|> Seq.filter (filterByQueryVisit query)
|> Seq.map (fun visit -> { mark = visit.mark; visited_at = visit.visited_at; place = locations.[visit.location].place})
|> Seq.sortBy (fun v -> v.visited_at)
Особенно Seq.sortBy волнует, который делает копию в массив и сортирует его.
Бенчмаркать я, конечно же, не буду. ?

Vasily
23.08.2017
13:14:55
Ну Seq.sortBy меня тоже смущает

Nikolay
23.08.2017
13:15:16

Evgeniy
23.08.2017
13:17:11

Dmitry
23.08.2017
13:18:36

Evgeniy
23.08.2017
13:19:19

Nikolay
23.08.2017
13:19:28
Насколько я помню, там были визиты конкретного юзера с фильтрами, и можно было бы сделать Dictionary, у которого ключ - ид юзера, а значение - визиты

Evgeniy
23.08.2017
13:20:07
Их бы еще сразу в сортированном виде держать.

Nikolay
23.08.2017
13:20:12
Плюс, можно заранее отсортированные по дате
Ха
Не успел дописать)

Vladimir
23.08.2017
13:21:03
точнее при апдейте визита
ну в общем эти массивы сейчас как джойны между таблицами
т.е. сохраняется нормализация по сути. можно конечно их и дальше денормализовать, но взятие массива по индексу и так быстрая операця

Nikolay
23.08.2017
13:23:16
Окей:
visits
|> Seq.filter (filterByQueryVisit query)
В query заложить id, или отдельно передать
Чтобы за один прогон отфильтровать

Google

Nikolay
23.08.2017
13:23:39
А данные хранить отсортированными

Vladimir
23.08.2017
13:23:43
оно и так один прогон при компиляции

Nikolay
23.08.2017
13:24:12
Но у тебя сейчас два раза map происходит, это разве оптимизируется?

Vladimir
23.08.2017
13:24:31
данные нельзя хранить отсортированными, сейчас они в массиве по айдишнику
эти все мапы и фильтры должны компилироваться в один проход
id = номер в массиве

Nikolay
23.08.2017
13:25:37
Ключ - id

Evgeniy
23.08.2017
13:25:59
С производительностью Seq приходит очень много вопросов.

Nikolay
23.08.2017
13:26:04
И получается отсортированы одновременно по id и visited_at
Хотя в данном кейсе первые 5 элементов не нужно обрабатывать
Правда не смотрел в Release, может там оптимизируется
Я проверял)

Evgeniy
23.08.2017
13:28:57

Vladimir
23.08.2017
13:29:09
что можно хранить отсортированными так это как раз индексы в листе)