ну там выигрыш только если у него много векторов

там копировать вообще ничего не надо

Эээ, что-то я торможу. Ну потому что объект db овнер + удобно все векторные штуки иметь + можно добавить если mut ну и тд

Эээ, что-то я торможу. Ну потому что объект db овнер + удобно все векторные штуки иметь + можно добавить если mut ну и тд

слайс указатель на память - вектор - копирование

Сорян, я не очень догоняю кто тогда слайсом будет владеть и ТД в другом случае.

слайс будет указывать на оригинальные данные

На оригинальные данные из внутренностей serde?!?

=)

на оригинальные данные из файла прочитанные

Ты файл в память читаешь?

Да

ну вот туда и будет указывать слайс =)

Стоп. Я как бы его не читаю, читает bincode

ну ммапни файл, дай бинкоду слайс

Стоп. Я как бы его не читаю, читает bincode

Вбрось код

Т.е. наверное нельзя сказать что я его читаю в память, а как раз не хочу этого делать.

а бинкод что делает по-твоему?

Вбрось код

Надо немного подготовить.

а бинкод что делает по-твоему?

Ну даже если он временно читает, то он читает прилично больше размера файла.

потому что он потом веки аллоцирует и копирует

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

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

И сделает за тебя всю черную работу?

И сделает за тебя всю черную работу?

Но ведь это именно зачем его изобрели.

берешь memmap крейт получаешь из него слайс памяти десериалайзишь в слайс бинкодом => 0 аллокаций

Но ведь это именно зачем его изобрели.

нет

берешь memmap крейт получаешь из него слайс памяти десериалайзишь в слайс бинкодом => 0 аллокаций

Вот я про это выше и написал, но Децл обидно что bincode что-то не оправдал ожиданий что ли.

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

Чтобы на выходе вернуть опять же структуру размером просто с файл.

Можно поворчать? Ожидал что Раст 🔥 на итераторах - оказалось не так, но хоть исправили. Ожидал что bincode будет быстрее молнии , и это не оправдалось, так ещё и память жрёт.

некоторые вещи специфичны

В большинстве случаев итераторы жгут

Из двух, что успел посмотреть - две специфичны :)

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

И все же к начальному вопросу, а вдруг поможет: где там serde аллоцирует? Вдруг какой хитрый флаг есть - типа экомить память .

Можно поворчать? Ожидал что Раст 🔥 на итераторах - оказалось не так, но хоть исправили. Ожидал что bincode будет быстрее молнии , и это не оправдалось, так ещё и память жрёт.

Раст вообще не 🔥 — HKT нет, impl trait нет, vararg нет, именованных аргументов нет, опциональных аргументов нет, специализации трейтов нет, const fn нет, наследования нет, замыканий на стеке нет...

толсто

Толсто — но всё правда

Щас бы именованные аргументы в Раст втащить

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

импл трейт в следующем стейбле так-то

Щас бы именованные аргументы в Раст втащить

Ну, мне лично не очень нравится, что вместо этого в Rust builder pattern абъюзят

Нахуй стэйбл нужен если в Найтли все есть

импл трейт в следующем стейбле так-то

Целиком или пока только conservative?

оба

почему абьюзят-то? .ty(pidor).and(sosal) vs (ty = pidor, and = sosal)

Нахуй стэйбл нужен если в Найтли все есть

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

Толсто — но всё правда

Опциональные аргументы не нужны

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

И? У меня за год последний ломалось пару раз. Фиксы занимали пару минут от силы.

fn f<I>(pook: I) where I: Into<Option<u32>> {} fn main() { f(5) } палю годноту пацаны

fn f<I>(pook: I) where I: Into<Option<u32>> {} fn main() { f(5) } палю годноту пацаны

Если бы ты был в гиттер чате тебя уже за пуки в аргументах забанили бы

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

Так было такое, фиксируйте тулчейн по дате и обновляй только если всё норм на последнем и надо.

Elasticaearch + filebeat

Хм, спасибо

В вашем игрушечном расте появились мемори лики

Ору

Ору

https://github.com/oru

В вашем игрушечном расте появились мемори лики

А они куда-то уходили?)

в продолжении bincode. Сделал просто сохранения Vec<String> и загрузка - и она 500Mb+ отжирает на de. Сам файл ~70Mb.

параллельный вопрос. почему mem::size_of_val на этот вектор показывает 24 всего? там ~2млн элементов же.

если сложить size_of_val строк внутри, то ~59Mb.

https://gist.github.com/mexus/099e92a1014f321de29638bf615e3475

измерения https://gist.github.com/mexus/1db435fdacdb828c008b8d45f7fb4ba2

а вот тоже самое для Vec<f32> проверил - есть оверхед, но вполне норм на фоне того что со строками происходит.

или я чёто не догоняю, или в моём примере оверхед 1.8 кб

я может не понял, но там 1.8Мb на ~10mln эээ, одно-двухбайтовых строк?

в смысле однобайтовых?

случайного размера, от 1 до 30

ааа, ok

тогда я торможу - как это всё вообще в 1.8Mb влезло?

-------------------------------------------------------------------------------- n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B) -------------------------------------------------------------------------------- 0 0 0 0 0 0 1 699,405 568 552 16 0 2 699,923 704 672 32 0 3 700,079 1,736 1,696 40 0 4 700,302 1,848 1,816 32 0 5 816,495 1,848 1,816 32 0

размер в байтах

(третья колонка)

как влезло — сам не понимаю

1.8kb???

у меня bufreader ещё, но он-то тут причём

он же буферизует, выделяя каждый раз память под данные

а файл норм размера? конечно сорян, очевидно, но не могу понять.

Denis, ну он вроде ~40kb буффер и всё

671 метр