AsRef и AsMut трэйты в #rust для упрощения кода. доку поправили, сейчас стало понятней
https://doc.rust-lang.org/std/convert/trait.AsMut.html
https://doc.rust-lang.org/std/convert/trait.AsRef.html

Dynamic storage allocation: A survey and critical review. In (1995)
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.143.4688
достаточно глубокий обзор на динамическую аллокацию памяти, фрагментацию, алаймент тп

https://www.youtube.com/watch?v=skos4B5x7qE Zero-Cost Async IO #rust. достаточно простое описание и сравнение

https://deterministic.space/secret-life-of-cows.html
статья про Cow в #rust. забавляет название "тайная жизнь коров" =)

https://llogiq.github.io/2020/03/14/ootb.html прикольная техника резервирования места, и для этого не нужно боксить (ложить явно в хип) а можно сделать просто резервацию

let t_holder;
let opt_t = if has_t {
    t_holder = get_t();
    Some(&t_holder)
} else {
    None
}

https://llogiq.github.io/2017/06/01/perf-pitfalls.html
#rust Performance Pitfalls
когда то нарвался на пару путктов отсюда

собственно для стэйт машин хорошо подойдет замена прямо из памяти, что бы не аллоцировать лишний раз в промежуточную переменную https://github.com/rust-unofficial/patterns/blob/master/idioms/mem-replace.md

во. шикарная статья про оптимизацию кода коровами (как же меня забавляет этот тип =)) в #rust

https://oribenshir.github.io/afternoon_rusting/blog/copy-on-write

https://oribenshir.github.io/afternoon_rusting//blog/enum-and-pattern-matching-part-1
https://oribenshir.github.io/afternoon_rusting/blog/enum-and-pattern-matching-part-2
про инамы и паттерн матчинг в #rust

https://oribenshir.github.io/afternoon_rusting/blog/closures и еще про замыкания в #rust определения Fn/FnMut/FnOnce мне нравится больше чем то что я читал в официалной доке

https://articles.bchlr.de/traits-dynamic-dispatch-upcasting шикарная статья про dyn типы, vtable, про полиморфизм и даже путь #rust в отношении имплементации наследования в C++ и апкастинг. сразу видна и проблема и то как явно это решается

https://anssi-fr.github.io/rust-guide/01_introduction.html небольшой гайд по секьюрному #rust. тут про библиотеки что помогают искать проблемы, утечки памяти, систему типов и ffi

https://medium.com/@pailee.wai/how-we-migrate-our-framework-into-async-await-c67b160e16be немного про миграцию старых фьюч на async/await в #rust

https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html чтото мимо меня промчался тот факт что больше в #rust не нужен mod.rs в каждой субдериктории

https://rust-lang.github.io/async-book/01_getting_started/01_chapter.html видел эту книгу, забыл про то что она есть. И как оказалось некоторые сложности с асинхронщиной в #rust, что я героически решил, в ней хорошо описаны 🙈

интересные результаты переписывания блокируюещго раста на async/await. хочу поделиться

дано:
16к строк кода в блокирующем многопоточном виде. хороший nvme SSD, гигобитная сеть, 24поточный Xeon 2678 в 3.3ГГц на ядро.

результат:
выигрыш отрицательный.
было 4.2сек сейчас 4.9сек. это проход 2000 файлов и пересчет параметров. жестко (для меня это большие цифры, если что). большее количество файлов имеет тот же эффект. поэтому обычно проверяю на этих 2к файлов с десяток раз, для правдоподобности, разброс малый очень

большую часть io задач у меня приходится на чтение с диска (цпу зубодробилку смысла нет на async/await переписывать). и когда куплен оч хороший nvme SSD то вообще оказывается в забрать в 24 потока блокирующе в буфер весь файлик быстрей. (фс настроена без лога времени доступа и тп, полностью под скорость) И возможно это уже приколы того как работает железо, шина и nvme, тут я уже теряюсь, может вы подскажете

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

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

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

неожиданные результаты для меня тем, что и вроде как круто что железо хорошее, но вот вопрос стоили ли мои две недели переписывания того или нет. если хороший nvme SSD Samsung 970 EVO Plus стоит всего 100$ (понятное дело можно найти и дешевле), и мне нужно заменить на 10тачках, то я попал в просак...

с другой стороны это мои первые потуги в стабильном асинхронном расте. Может кто работал с ним уже ? я вот 100% уверен что чтото упустил, и можно дотюнить.

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

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

https://k6.io/ тула что бы деть стресс и нагрузочные тесты апишек. надо не забыть, явно пригодится скоро.
скриптом можно сэмулировать любые перепады трафика и отхэндлить любые косяки разными способами (счетчиками, рейтами и т.п.)

https://engineering.mongodb.com/post/getting-storage-engines-ready-for-fast-storage-devices статья очень мне в тему сейчас. про Memory-mapped files для ускорения работы с диском

https://www.youtube.com/watch?v=8cV4ZvHXQL4 забавный оч старый но хороший доклад про то как работает eventloop в #js не видел перевода до сегодня