Если уж мы про удаление

То лучше Hashset

Чем лист

А чо вы делаете, народ?

Может, и правда персистентным вектором фигануть, а?

Правда, он мусорит при модификациях.

Ну я провожу диванную аналитику

Решения hlcup

от мейлрушечки

потом его нужно замапить, ResizeArray по мне так отлично подходит

idlist -> map getEntityById

HashSet - та же последовательность

на гетах нужно будет мапить на каждом третьем запросе

Тут ничего не поменяется

Может стоит подождать до 1 сентября, там много людей с избытком свободного времени отсеется.

Так и мы сами тоже отсеемся ?

Тут ничего не поменяется

список ключей из хэшсета разве не медленней получить чем просто список?)

список ключей из хэшсета разве не медленней получить чем просто список?)

Не понял вопроса

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

Hashset

что там будет ключом что значением?

Ты с Dictionary не путай

Разные вещи

В F# есть стандартные множества какие-то.

Ну надо смотреть, что есть, да

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

HashSet<int> жеж

пойду гуглить)

Давай

Кстати, онолитеги

Сколько у нас там операция удаления из листа? O(n)?

да

Ну, типа да.

Из ResizeArray, кстати, тоже :)

А из хешсета O(1), как я понимаю

(но это худший случай)

Хотя не

у рейсайзАррея это любой случай же

Нет.

Если из конца удалять, то будет быстро.

Там худший, когда все совпадают хеши

Если удалять по индексУ, то быстро

А тебе надо по значению? Тогда медленно, ага.

https://msdn.microsoft.com/ru-ru/library/cd666k3e(v=vs.110).aspx

О, а у хешсета действительно О(1)

Не все я еще растерял на энтерпрайзных галерах

Хотя худший у хешсета все же O(n)

В определенном случае

Но это не наш вариант

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

На самом деле там самые большие потери при десериализации скорее всего

Я имею в виду в решении для hlcup

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

ну обычно, там 32 основание делают, да.

Но, да, утверждение в целом верное, вектор это не серебряная пуля.

Серебряных пуль вообще нет

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

я очень извиняюсь, не могу пока подискутировать, надо поработать, вечером вернусь)

Подскажите, пожалуйста. Я правильно помню, что цепочки с 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 волнует, который делает копию в массив и сортирует его.

Бенчмаркать я, конечно же, не буду. ?

Ну Seq.sortBy меня тоже смущает

Подскажите, пожалуйста. Я правильно помню, что цепочки с 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)

А почему нельзя сперва filter сделать, а затем map?

А почему нельзя сперва filter сделать, а затем map?

По логике нельзя. Посмотри внимательнее. Сначала берем визиты по ключам, потом их фильтруем, готовим записи для ответа, сортируем их.

По логике нельзя. Посмотри внимательнее. Сначала берем визиты по ключам, потом их фильтруем, готовим записи для ответа, сортируем их.

а почему нельзя брать визиты по ключам в фильтре?

а почему нельзя брать визиты по ключам в фильтре?

Я думаю, можно.

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

Их бы еще сразу в сортированном виде держать.

Плюс, можно заранее отсортированные по дате

Ха

Не успел дописать)

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

тогда при апдейте юзера нужно апдетить не только юзера но и эти словари

точнее при апдейте визита

ну в общем эти массивы сейчас как джойны между таблицами

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

Окей: visits |> Seq.filter (filterByQueryVisit query)

В query заложить id, или отдельно передать

Чтобы за один прогон отфильтровать

А данные хранить отсортированными

оно и так один прогон при компиляции

Но у тебя сейчас два раза map происходит, это разве оптимизируется?

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

эти все мапы и фильтры должны компилироваться в один проход

id = номер в массиве

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

https://msdn.microsoft.com/en-us/library/f7fta44c(v=vs.110).aspx

Ключ - id

С производительностью Seq приходит очень много вопросов.

И получается отсортированы одновременно по id и visited_at

С производительностью Seq приходит очень много вопросов.

Кстати да, например такой код: [0..10] |> Seq.map (fun x -> x * x) |> Seq.skip 5 Сделает сперва map всех элементов, а затем пропустит 5

Хотя в данном кейсе первые 5 элементов не нужно обрабатывать

Правда не смотрел в Release, может там оптимизируется

Я проверял)

эти все мапы и фильтры должны компилироваться в один проход

Я бы не был так уверен, что все скомпилируется оптимальным образом. В visualfsharp очень долго пытаются заставить Seq работать так, чтобы все компилировалось правильно, а операции фьюзились.

что можно хранить отсортированными так это как раз индексы в листе)