SS
пока что как-то так)
Size: a a a
2019 August 28
SS
в базу еще не упаковал, но по крайней мере парсинг в 0.2 сек — возможно, будет интересно)
SS
всмысле, на файл. всего ожидается около 130*0.2 , ну то есть около минуты. причем ускорить можно запросто
SS
тупо сразу складывая в базу, а не аллоцируя тюплы и не перегоняя их туда-сюда
SS
всмысле, на файл. всего ожидается около 130*0.2 , ну то есть около минуты. причем ускорить можно запросто
130*0.2 = 26 сек ? "около минуты" — бог арифметики
AB
по скорости норм. посмотри, что с потреблением памяти
SS
ну пока 100 метров, если все в один список тупо складывать. но тут же бинари копируются, ничего удивительного
SS
при норм упаковке в базу это все должно убраться
SS
в нифках кстати, есть замечательная штука enif_make_subbinary — можно из любого бинаря сделать слайс
SS
жаль, эта фича в обычном эрланге хреново работает. в binary_split по-моему только. ну может еще в binary:part, но там смотреть надо
AB
надо попробовать. я обычно новый бинарь делал в своем ниф. и оказалось медленнее, чем binary.part. наверное поэтому как раз
SS
ну у меня парсятся строки в один так сказать, бинарь)
SS
на си
SS
т.е. у Account поле string_data — там все данные
SS
а чтобы обратиться конкретно, скажем, к email или fname/sname, сделаны небольшие обертки в виде StringRef{ u32 offset, u32 size }
SS
почему не std::string_view спросят знающие люди — отвечу, потому что sizeof(std::string_view) = 2 * 8 = 16 байт, и там работа с указателями. мне удобнее хранить индексы по смещению внутри. у меня же u32 + u32 = 8 байт, хотя хватило бы и u16 на самом деле
AB
идею понял. я вот еще от utf отказался и перекодировал все в win1251 ))) чтобы каждая буква в байт помещалась )
SS
не-не, это ты зря
SS
потом при выводе обратно придется
SS
вот от эскейпинга — да, стоит отказаться