вот здесь https://github.com/bochsdbg/hlcup2_ex/blob/master/lib/hl_cup.ex#L8 должен быть акутальный тюпл с 12тью или 13ю элементами

IO.inspect item

такс, сегодня вот руки дошли — сделал

общее время на распаковку и добавление в базу — около 45 секунд, база 370 метров

еще можно сэкономить, сделав поля has_primary, has_phone и другие необязательные, где 1 бит на поле has_* даст какой-то выйгрыш. ну и interests можно кодировать поплотнее, при желании (не по 8 бит на интерес, а по 7)

ну или для бОльшей производительности, наоборот, добавить побольше битности, посмотреть по выравниванию (заодно можно из бинаря считывать будет по индексам бОльшую часть полей)

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

где-то там по 60 метров на файл выходило, что слишком много. но все же в бинарь удобнее упаковывать и распаковывать его, чем в длинные числа)

да, и интересы, насколько я помню, там особо не нужны, на самом деле (насколько я помню, там нет запросов вида get_interests_by_account_id). там нужен индекс (типа gin) interest -> account_id, лайки кстати тоже. но по лайкам приходится строить прямой и обратный индекс для некоторых запросов. думаю, что могут влезть и лайки, если списки [id1, id2, id3, ...] хранить в виде «id1 :: 24, id2 :: 24, id3 :: 24, ...», по три байта на id там должно хватать.

ну а вообще, сама база-то фигня, вся сложность — это именно индексы представлять. и делать пересечения по этим индексам. и вот тут как раз оверхед ets даст о себе знать: если в плюсах можно в теории один индекс сохранить в 1300000*4 — где-то в 5 метрах, то в эрланге к этому как минимум добавится 6 байт на запись. в итоге в память поместится гораздо меньше индексов, ну и пересечения считаться будут, разумеется, заметно медленнее. и именно в этом сложность решения этой задачи на эрланге/эликсире.

Привет, друзья!
Кто может подсказать, хочу использовать Mox для тестирования запросов, теструю я модульно, иногда тест пишется на какой нибудь отдельный flow, и call к созданому mock’у происходит внутри флоу.
Вопрос, могу ли я получить список этих вызовов? В идеале я бы видел что то подобное`HttpMock.list_calls()` .
В документации информации об этом не вижу, заранее спасибо

А *какую* информацию о вызове ты хочешь увидеть? Переданные аргументы? caller?

В API такой функции нету, но в зависимости от хотелок, можно попробовать реализовать самому

Переданные аргументы, верно

Если не трогать исходники Mox, то самое простое — это внутри expectation самому руками сохранять информацию о вызовах в ets/GenServer/Agent.

+

запустить GenServer и хранить в нем стейт

Если трогать исходники Mox, то всё доступно внутри функции __dispatch__

Можно делать это не руками, а через трассировку вызовов, тогда expectation менять не придётся