These are chat archives for rust-lang/rust

28th
Oct 2016
Pavel Penkov
@PavelPenkov
Oct 28 2016 15:27
I have a question regarding memory management in Rust. Historically people wrote custom allocators when they needed high performance to deal with memory fragmentation and to be able to free a lot of memory in one fell swoop. As far as I understand Rust uses what is essentially a reference counter. Is its memory management fast enough?
Kang Seonghoon
@lifthrasiir
Oct 28 2016 15:28
reference counting is a (though simple) garbage collection scheme. the main benefit of Rust is that you can avoid most GC uses with safe borrowing.
Pavel Penkov
@PavelPenkov
Oct 28 2016 15:30
As far as I understand, Rust frees memory as soon as object goes out of scope which is very similar to what reference counting GC does.
Kang Seonghoon
@lifthrasiir
Oct 28 2016 15:31
it does, but reference counting requires that the count is stored alongside with the value, and the count has to be decremented and incremented continuously
you don’t pay that cost for most cases in Rust
@PavelPenkov if you want, you can thought that Rust is very strongly optimizing RC system, so much that it eliminates the reference count in the fields in most cases. in reality it does the opposite thing though: borrowing is default, and you only use RC when the borrowing is not enough, and you only .clone() (i.e. increase the reference count) when it is probably required.
in total it results in a performance characteristic similar to the highly optimizing RC, but very predictably.
Pavel Penkov
@PavelPenkov
Oct 28 2016 15:34
Hm, I'm really bad at explaining what I mean. Suppose I'm writing a C program, allocating memory with malloc and freeing it as soon as objects go out of scope. Its unsafe but suppose I'm careful enough and everything works fine. As far as I understand this approach was considered "slow" and people wrote custom allocators to avoid memory fragmentation and free multiple objects at once
Kang Seonghoon
@lifthrasiir
Oct 28 2016 15:34
it is not always slow if the allocator is smart enough.
for example, performant allocators will optimize for the fixed-size small allocations
Diggory Blake
@Diggsey
Oct 28 2016 15:35
rust uses jemalloc by default, which is already heavily optimized
and rust favours directly storing things on the stack when possible (ie. when they have a fixed and relatively small size)
Kang Seonghoon
@lifthrasiir
Oct 28 2016 15:36
yeah. you don’t have to worry much about the allocator performance, though if you need you can use the “arena” style allocators in third party crates.
Diggory Blake
@Diggsey
Oct 28 2016 15:37
there's also a crate which supports a Vec that stores its items on the stack until they exceed a predefined limit, and only then does it try to allocate on the heap
Kang Seonghoon
@lifthrasiir
Oct 28 2016 15:37
isn’t the smallvec crate for the stack only allocation?
ah, I didn’t know that it is always hybrid
Maciej Hirsz
@maciejhirsz
Oct 28 2016 15:43
@PavelPenkov Rust basically does what you would do in C, it just automates the process. Instead of writing malloc you just create something like a new Vec or Box (or anything else that uses heap), and the compiler will insert a free instruction for you for when the owner of that heap allocated value runs out of scope.
There are some special cases when it’s not exactly known at runtime when the value ought to be freed and then drop flags are being added to runtime, but those situations are pretty rare.
there are reference counted types (Rc and Arc) when you do want to use reference counting and don’t want to deal with the borrow checker, but you have to explicitly invoke them, you can write programs and libs that never use ref counts
Pavel Penkov
@PavelPenkov
Oct 28 2016 15:48
it's pretty cool that you can use custom region-based allocators if needed. the language is awesome unfortunately, I don't write stuff where it's usage is justified.