D
ну вот персистентная структура в хаскелле работает со скоростью мутабельного вектора в жабе
ну вот к сожалению если ты хочешь сделать индекс для базы данных, ты не берешь персистентную сд
Size: a a a
2020 April 11
DS
Dima
Ну так тогда вообще никаких проблем нет
Разница в том, что с персистетными структурами данных не надо париться с defensive copying вообще
DS
Это в достаточно ощутимом числе случаев может очень сильно помочь
DS
Я видел приложения, где большая часть memory pressure была именно из-за defensive copying.
D
ну так всегда проблемы из-за этого
AZ
Dima
ну вот к сожалению если ты хочешь сделать индекс для базы данных, ты не берешь персистентную сд
очередной аргумент что лимузин куда хуже запора, потому что у него в багажник картошки меньше помещается
D
очередной аргумент что лимузин куда хуже запора, потому что у него в багажник картошки меньше помещается
лол
RP
Dima
ну вот к сожалению если ты хочешь сделать индекс для базы данных, ты не берешь персистентную сд
если хочешь сделать индекс для базы, которая умеет в ACID, ты берешь персистентные коллекции
D
если хочешь сделать индекс для базы, которая умеет в ACID, ты берешь персистентные коллекции
я не хочу этого
DS
Dima
ну так всегда проблемы из-за этого
У персистетных структур данных суть в том, что таких проблем при их использовании не будет
D
я хочу FASTER от того же ms
D
или lmdb
D
где там персистентные сд?
DS
Т.е. если ты видишь, что ты много теряешь на копировании в том или ином виде - то вот тут и нужны персистетные структуры данных.
В других случаях - вряд ли
В других случаях - вряд ли
D
Т.е. если ты видишь, что ты много теряешь на копировании в том или ином виде - то вот тут и нужны персистетные структуры данных.
В других случаях - вряд ли
В других случаях - вряд ли
ну окей
DS
Dima
ну окей
Т.е. по этому они и актуальны в ФП, где обычно куча копирований и бывает
RP
Dima
где там персистентные сд?
The log allocator design presented in the previous section, in ad-dition to handling data larger than memory, enables a latch-freeaccess path for updates due to its append-only nature. But thiscomes at a cost: every update involves atomic increment of the tailoffset to create a new record, copying data from previous locationand atomic replace of the logical address in the hash index.
RP
из пейпера
RP
прикинь, да?
D
The log allocator design presented in the previous section, in ad-dition to handling data larger than memory, enables a latch-freeaccess path for updates due to its append-only nature. But thiscomes at a cost: every update involves atomic increment of the tailoffset to create a new record, copying data from previous locationand atomic replace of the logical address in the hash index.
так они его выкинули в итоге