AB
время перекодирования в расчет не брал, тк оно и так все медленное. а вот в память не помещался и надо было что-то делать
Size: a a a
2019 August 28
SS
ну я тоже вначале хотел, но потом прикинул, что при выводе ж обратно придется перекодировать — и передумал
SS
инты маленькие помещаются похоже в 4 байта, как написано в http://erlang.org/doc/efficiency_guide/advanced.html
AB
подходящей навскидку реализации хеша тоже не нашел
SS
поэтому есть смысл повторяющиеся строки перекодировать в числа
SS
тем более что там где-то еще какой-то лексикографический порядок нужен, а не побайтовый
SS
можно id-ы присвоить такие, чтоб сравнивалось как нужно, а не перекодировать каждый раз
SS
ну т.е. так же как индексы по сути в любой субд сделаны
AB
и да. города, имена, и все такое - у меня таки было словарями. то есть, отдельными таблицами. а в таблице с данными хранились именно индексы из этих таблиц
SS
подходящей навскидку реализации хеша тоже не нашел
ты про phs ? не, это советую делать уже потом, когда уж совсем заняться нечем будет. это микрооптимизации. http://cmph.sourceforge.net/index.html что-то типа этого, хотя еще где-то либу видел, их нужно еще сравнить
SS
индексы — числа?
SS
до 2^30 ?
SS
странно тогда, а на что тогда память уходила?
AB
ну да. там только единственное, надо было решить вопрос проверки на уникальность. чтобы 2 раза не добавлять один и тот же город. плюс это в мультитреде должно было работать, тк я параллельно данные обрабатывал
SS
ну само собой
SS
хотя добавлять совершенно не обязательно в мультитреде
SS
лишний геморрой)
SS
ets же вроде не умеет атомарно в две разные таблицы писать?
SS
мнезию вроде брать не хочется
SS
или там есть возможность как-то secondary index прикрутить, к ets-ке?